LINUX.ORG.RU
ФорумTalks

Галерка хочет мигрировать из Haskell в Rust, но не знает зачем

 ,


1

8

Дано (на самом деле этот раздел можно пропустить, чтобы не читать простыню, он написан во избежание лишних вопросов): друг работает в конторе с достаточно широким полем деятельности, но повсюду применяющей микросервисную архитектуру, либо просто разрабатывающую небольшие утилиты вроде драйверов, так что, вопросы легаси и т.п. не стоят. Миграция из языка в язык достижима практически без накладных расходов. Уже используются: haskell, c++ + asm, go. Для менее требовательных задач python, ruby, java. К первой тройке недавно добавился rust. Язык весьма зашёл некоторым разрабам, но не всей команде. Прямой руководитель сперва был воодушевлён, но результаты внедрения на практике оказались не столь впечатляющими. Если я правильно понял, ранее написанный драйвер на хаскеле, был переписан на Rust. Там переписывание одного и того же - нормальная практика, так как реальное оборудование не всегда совпадает с тестовым и документацией. Поэтому сперва делается тестовый образец на хаскеле/го, а затем — всё переводят на плюсы. Сейчас попробовали перейти на rust. Оказалось, что линуксовый драйвер написанный на rust с тем же алгоритмом выиграл всего лишь на 4% у хаскельного драйвера (да я тоже удивился, что они используют язык с gc в драйверах, но оказалось, все довольны), при этом разработка заняла 5 недель вместо чуть меньше месяца на хаскеле. Ок, чтобы совсем уж код на rust не выкидывать, переписали с ассемблерными вставками (там это норма). Всё бы ничего, и решили, что если бы писали на плюсах с асмом, вышло бы также по скорости. Вот только, вставки на асме заняли 40% полезного кода (для плюсов там такое тоже норма) и весь драйвер был в unsafe. Короче, они там пришли к выводу, что когда вставок на асме становится слишком много, проще взять плюсы, типа там даже безопаснее получается. Итого, rust рассматривают как замену go и хаскеля. Первых уже потеснили, значит очередь за хаскелистами. И тут разгорелась локальная «святая война». Хаскелисты утверждают, что haskell с монадками и клёвой типизацией якобы на практике не хуже раста, и даже безопаснее. Т.к. кто кого безопаснее пока не выяснили, а аргументы хаскеллистов не понимает никто, кроме них самих, вопрос пока подвис. Конечно, скорее всего они там сами разберутся, чай не дураки, гуглить умеют, но вдруг здесь у кого есть интересное чтиво по данному вопросу.

Самому мне всё равно: с одной стороны, оба языка мне нравятся, с другой, лично для моих задач они не подходят. И к сабжевой конторе отношения не имею. А вот друг - там и имеет некоторый интерес перейти с плюсов на раст (на го и хаскель не хочет), подыскивает доводы, чтобы убедить начальство.

Собственно вопрос: где бы найти почитать взвешенный сравнительный анализ хаскеля и раста? Там с нормальным сравнением производительности, особенно (!) безопасности и прочее.

★★★★★

Последнее исправление: next_time (всего исправлений: 1)
Ответ на: комментарий от lazybones

При чем здесь stack, cabal и академичность ?

Я спрашивал, что изменилось - Haskell перестал быть академической игрушкой? Когда? Что именно произошло - появился cabal? Появился stack?

А cabal и stack академичны в том смысле, что работа академиков - пробовать один подход за другим и публиковать результаты. Что происходит с разработанным кодом, их заботит мало.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 2)
Ответ на: комментарий от tailgunner

Haskell перестал быть академической игрушкой? Когда?

очевидно, для ответа на этот вопрос вы должны предоставить своё определение «академической игрушки»

next_time ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

stack в таком случае как раз неакадемичен, так как является лишь надстройкой над cabal и сохраняет обратную совместимость, то есть к cabal-проекту можно добавить надстройку stack-а. И наоборот - проект, созданный при помощи stack можно собрать кабалом.

lazybones
()
Ответ на: комментарий от dave

Да ты не в теме!

Да, Холмс! Вы догадались об этом по моему «я не слежу за Haskell»? Я не в теме и пытаюсь выяснить, что такого случилось с Haskell, раз как минимум один человек перестал считать его академической игрушкой.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от tailgunner

Stack дает воспроизводимость сборки. Это более, чем довод так думать.

Последние годы редко ломают обратную совместимость, но тогда спасает stack. Вот, сейчас полугруппы обязательные вводят для моноидов, но благодаря stack можно особо не торопиться.

Касательно противопоставления cabal и stack. Вот сегодня я только проверял сборку проектов cabal разными версиями GHC с помощью stack. Фантастически удобно

dave ★★★★★
()
Последнее исправление: dave (всего исправлений: 1)
Ответ на: комментарий от dave

Я не в теме и пытаюсь выяснить, что такого случилось с Haskell, раз как минимум один человек перестал считать его академической игрушкой.

Stack дает воспроизводимость сборки. Это более, чем довод так думать.

Ммм... нет. В «промышленности» уже десятки лет используются системы сборки, которые этого не гарантируют. Конечно, воспроизводимость сборки - это круто, но это прежде всего академический успех (который, конечно, полезен в практической работе).

Кстати, воспроизводимость сборки - это побитовое соответствие собранных артефактов? stack как-то записывает версию тулчейна?

Последние годы редко ломают обратную совместимость, но тогда спасает stack

Можно об этом подробнее (или ссылку)?

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от tailgunner

Stack фиксирует версию компилятора ghc и версии самых основных библиотек cabal, гарантируя, что они совместимы друг с другом. И мне показалось, что для такой всей из себя особенной системы Windows даже предоставляет уже заранее собранные бинарники некоторых библиотек, потому как на чистой Windows с тулчейном могут быть большие-пребольшие проблемы, а haskell - платформа, где почти все собирается из открытого кода.

Я под воспроизводимостью имею в виду, что на выходе получим функционально тот же бинарник и через 5-10 лет на всех поддерживаемых операционных системах. На счет побитового сравнения я бы не заморачивался. Не думаю, что это кого-то особо волнует.

Кроме того, stack позволяет подключать сторонние пакеты cabal, да хотя с того же github или с локальной файловой системы, или с чего-нибудь типа nexus, что важно для закрытой коммерческой разработки.

В простейшем случае переключиться на другую версию ghc и более новые версии библиотек - это изменить одну строку в текстовом файле.

dave ★★★★★
()
Ответ на: комментарий от dave

Я под воспроизводимостью имею в виду, что на выходе получим функционально тот же бинарник и через 5-10 лет на всех поддерживаемых операционных системах. На счет побитового сравнения я бы не заморачивался. Не думаю, что это кого-то особо волнует.

Разработчиков Rust волнует именно побитовая идентичность. Вообще требование редкое, но не уникальное.

В простейшем случае переключиться на другую версию ghc и более новые версии библиотек - это изменить одну строку в текстовом файле.

А есть в сети какая-нибудь мурзилка по stack?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

А есть в сети какая-нибудь мурзилка по stack?

Не в курсе. Не искал. Я довольно быстро освоился со stack после опыта с cabal.

dave ★★★★★
()
Ответ на: комментарий от tailgunner

stack как-то записывает версию тулчейна

Угу. См LTS. Более того, голый стек этот тулчейн автоматом разворачивает.

lazybones
()
Ответ на: комментарий от tailgunner

А есть в сети какая-нибудь мурзилка по stack?

На русском? https://ruhaskell.org/posts/utils/2015/07/13/from-cabal-to-stack.html

Для меня великий профит в том, что стало легче разворачивать несколько сборочных окружений на 1 машине. Ну и зависимости, да)

lazybones
()
Ответ на: комментарий от tailgunner

А cabal и stack академичны в том смысле, что работа академиков - пробовать один подход за другим и публиковать результаты. Что происходит с разработанным кодом, их заботит мало.

Всё таки не совсем так, по моему. Если я верно понимаю, кабал был решением чисто практической проблемы, мало волнующей академию, а именно проблемы зависимостей. Ну кому в самом деле какая в академии разница какие там зависимости? просто снеси хаскель платформ, поставь новую версию да и продолжай писать статьи. Ну или сиди до упора на старой версии и читай лекции/принимай практику у студентов. Там проблема зависимостей минимальна по моему. В отличие от практики, где зависимости одна из основных проблем сборки.

И проблему зависимостей кабал решил, но принёс с собой cabal hell, т.е. проблему конфликта зависимостей. Её можно было решать через кабал сандбокс руками в общем то, но я не знаю на сколько это было хорошо, я не застал. Это тоже чисто практическая проблема: если у тебя там полтора проекта один для статьи и один для студентов проверять задания, то ты вполне можешь настроить себе песочницы руками, а вот если тебе нужно часто устанавливать/удалять проекты в команде, то там такой подход работает плохо и не масштабируется совершенно.

Как решение проблемы cabal hell пришёл стек, который использует кабал и добавляет сверху него дополнительную информацию и функционал. Со стеком установка нескольких разных версий компилятора и библиотек для разных проектов стала обычным рутинным делом. Установка нового проекта сводится к stack install и это полностью ставит компилятор и библиотеки, можно просто работать. Вряд ил это нужно академии. Ну, по крайней мере до такой степени чтобы с этим заморачиваться, кмк.

AndreyKl ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.