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)
Ответ на: комментарий от dave

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

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

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

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

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

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

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

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

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

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

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

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