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

Эээээээээээээээ. Серьезно? Ваша самая частая (ну или может самая трудноотлавливаемая) ошибка - символ в другой раскладке? Серьезно?

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

Гмм, пример выше довольно очевиден для любого, кто работает с ленивым языком, ничего подводного тут нет ;-)

И да, если вкратце, как работают ексепшны в Rust? Только через АДТ?

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

Гмм, пример выше довольно очевиден для любого, кто работает с ленивым языком, ничего подводного тут нет ;-)

Большинство проблем вызывающих сегфолты на сях так же очевидны для любого пишущего на сях. Но это не мешает быть сегфолтам занозами в жопе.

И да, если вкратце, как работают ексепшны в Rust? Только через АДТ?

Да. Технически можно еще кидать «panic!», а потом отлавливать, но создатели раста говорят, что это плохо. Во всех существующих либах механизм ошибок реализован через АДТ.

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

Если считать только те ошибки, на поиск + исправление которых я потратил больше примерно минуты - двух(за вычетом времени на пересборку и запуск ПО) || те, которые дошли, хотя бы, до тестов, то за последний год мои ошибки делятся на 4 категории:

1) Ошибки или переделки ТЗ. Неисчислимое множество. На это, я есс-но никак повлиять не могу.

2) Недоделки - типа не успевал сделать всё сразу, часть вернулось в редмайн в виде новой задачи с пометкой баг. Аналогично, с этим ничего не поделаешь. 31 такая ошибка за 2017 год (редмайн посчитал).

3) Извечные проблемы с гуем - у меня оно выглядит нормально, а у заказчика при определённых обстоятельствах оно расползается. Это QT 4-ка, детка: якори завезли, но только в Qt Quick, который у нас не юзается. Около двух десятков таких задач за год. Не допускать такие задачи до релиза можно, но непрактично, т.к. заказчик хочет в основном ехать, а не шашечки, а полноценное тестирование гуя - занятие довольно занудное.

4) Дурацкие опечатки, вроде тех, что выше. Не больше 5-и таких ошибок за последний год. Одна из них довольно печальна: в определённых обстоятельствах в следствии ошибки в cmake файле подгружалась не та версия .so и вызывала segmentation fault, ошибка дошла до тестеров, и хотя я её быстро поправил, она стала моей первой segmentation fault в реальном коде за последних лет 7-8 разработки. Довольно позорно, но факт.

Итого: да, за последний год, например, за вычетом ошибок, на существование которых нереально повлиять и быстро поправленных, 100% моих ошибок были совершены в результате дурацких опечаток, которые, тем не менее, скомпилировались.

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

врут?

Томпсон и Ритчи посчитали, что им не хватает контроля над космическим кораблём для того, чтобы избегать столкновений с некоторыми камнями. Поэтому они решили перенести игру на свободный PDP-7, стоящий в офисе. Однако этот компьютер не имел операционной системы, что заставило их её написать. В конце концов, они решили перенести эту операционную систему ещё и на офисный PDP-11, что было очень тяжело, потому что её код был целиком написан на ассемблере. Было вынесено предложение использовать какой-нибудь высокоуровневый портируемый язык, чтобы можно было легко переносить ОС с одного компьютера на другой. Язык Би, который они хотели сначала задействовать для этого, оказался лишён функциональности, способной использовать новые возможности PDP-11. Поэтому они и остановились на разработке языка Си.

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

это должен быть варнинг, а там уже сами думайте

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

А вы сами-то когда в последний раз сегфолт встречали? Мне можете не верить. Но вот, допустим, гном/кде/explorer.exe что у вас там: когда оно у вас в последний раз с сегфолтом падало? Или вот ещё вариант: андроид. Я в курсе, что 99% в нём на жабе. Но сама-то жабомашина - на сишечке. Ну и как часто она у вас сегфолтится? Нет, дорогу в багтрекер я сам найду - вы про свой личный опыт расскажите.

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

А при чём тут ФМ? И тем более андроид? Я про свой код говорю, а не про чужой. Падает оно или нет - роли не играет. Вопрос был про частоту ошибок, и сегфолты тут на первом месте. И это не я придумал. Смотрите списки CVE.

На андроиде вылетания - норма жизни. Говорю не про себя, а про знакомых, которые на это жалуются (да, у всех китайцы).

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

А при чём тут ФМ?

При том, что оно тоже написано на С либо С++. Хорошо, расскажите про другой софт, написанный на сишечке/плюсах более-менее вменяемыми людьми: IDE, браузеры, GNU utils, bash наконец.

И тем более андроид?

не андроид, а жаба машина, которая написана на С

Я про свой код говорю

ну расскажите, хотя бы, про свой: как часто вам в редмайн, жиру или что у вас там возвращаются заведённые задачи об исправление сегфолтов в вашем коде?

Говорю не про себя,

чтд

На андроиде вылетания - норма жизни

я вам не про вылетания, а про сегфолты

а про знакомых

которые, небось, сегфолт от nullpointer exception не отличат - толку-то от их отзывов

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

я почему спрашиваю: если прикинуть, то за вычетом разных бета-версий софта и софта, запущенного под вайном, я сегфолты-то давнееенько не встречал

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

Сегфолты ладно, их сразу видно. А гейзенбаги? Порча стека или кучи, неинициализированные переменные могут и не привести к сегфолту. Сегфолт - это лучшее, что может в таком случае произойти.

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

NPE — частный случай сегфолта, просто отловлен проверкой раньше, чем приложение было прибито ядром.

В Rust абсолютный null safety, в отличие от C++ и жабы, раз уж о ней заговорили.

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

NPE - это жабопроблемы. А я про плюсы.

раз уж о ней заговорили

нет, говорили про жабамашину, которая на сишечке

//У нормальных людей, я и NPE-то не видел. Например, ни один из моих jme телефонов не выкинул nullpointer exception ни разу.

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

Исходники есть? А то там может быть и

    try {
        doSomething();
    } catch (NullPointerException e) {
        System.out.print("Улыбаемся и машем");
        restart_app();
    }

На андроиде за последний месяц приложения раза три вылетали, два - зависали.

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

А гейзенбаги?

Вот! Гейзенбаги образуются в результате нарушений программной логики. Из существующих ЯП только функциональщина вроде хаскеля и заставляют писать в таком стиле, чтобы их избегать. Собственно, потому и возник топик.

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

Исходники есть? А то там может быть

а мне как юзеру наплевать, что там может быть, если оно в результате прекрасно работает

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

об исправление сегфолтов в вашем коде?

Почти никогда. Но это не спасает от сегфолтов на этапе разработки. О чём и речь.

я вам не про вылетания, а про сегфолы

Как разница? Главное что прога упала.

Вы прямо свидетель безопасной сишки. А я думаю, откуда вылазит столько людей с воплями о том, что начиная с C++11 проблем с памятью в C++ больше нет. Так это вы.

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

Почти никогда.

чтд

Но это не спасает от сегфолтов на этапе разработки. О чём и речь.

да, было бы нелишним, если бы в плюсы добавили безопасный режим, как в раст

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

Но это не спасает от сегфолтов на этапе разработки. О чём и речь.

да, было бы нелишним, если бы в плюсы добавили безопасный режим, как в раст

Так добавили же уже — именно что для этапа разработки и тестирования — санитайзеры.

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

Ну, доказать отсутствие просто - глянул в багтрекер: нет там ошибок - значит нет. Прямо как чайник Рассела.

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

Не... Пистонисты - это отдельный диагноз. А у меня всё просто: если баг не заведён - значит юзерам, заказчику, а главное работодателю - всё равно - меня-то в таком случае почему должно колыхать? Особенно, учитывая, что я сейчас не ядерные системы пишу и не пожарную сигнализацию, а банальный гуй?

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

Haskell не дает возможности по типу функции определить безопасна она или нет: print и writeIORef x имеют одинаковый тип, но первая безопасна, а вторая — нет. В Rust же корректность доступа к памяти может быть доказана компилятором.

эм... зато writeTVar и print имеют разный тип. И я знаю по типу, что writeTVar никогда ничего не выведет на экран и не запишет в файл.

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

Ты, полудурок. Опять начинаешь, ебучий шакал.

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