Вы уже готовы к драйверам, написанным растамакаками?

Прочитал как растаманами - в таком контексте ни чего страшного не увидел.

Хотя стандартная библиотека Rust тоже местами поражает своей неадекватностью.

Кстати да, citation needed. Сугубо в рамках личного любопытства, что тебя не устроило в стдлибе раста?

Пока еще лучше подвисаний без таймаутов, без индикации, с погашенным экраном

Хотя стандартная библиотека Rust тоже местами поражает своей неадекватностью.

Кстати да, citation needed. Сугубо в рамках личного любопытства, что тебя не устроило в стдлибе раста?

Классический пример: трейт From, который позволяет кастовать практически что угодно в практически что угодно, даже если это особо не имеет смысла. Ещё вездесущий .unwrap(), на использование которого библиотека просто толкает и пинает.

Мы учились водить на жигулевской классике зимой, мы в курсе, что такое «паника при необработанной ошибке», а вы тут третий месяц обсуждаете снежинкопроблемы.

Мы учились водить на жигулевской классике зимой

Два чая!

трейт From, который позволяет кастовать практически что угодно в практически что угодно, даже если это особо не имеет смысла

А что с ним не так?

Я бы понял, если бы ты жаловался, скажем, на Into и его blanket impl Into<T> for U where T: From<U>. Но From чем не устроил — было бы лучше, если бы в каждом типе была пачка разношёрстных from_type()?

Ещё вездесущий .unwrap(), на использование которого библиотека просто толкает и пинает

Каким образом?

Опять же, я бы понял близкую (но структурно иную) претензию к тому, что std неконсистентно относится к ошибкам выделения памяти, и в результате у тебя рядом лежат, скажем, write!() (возвращающий Result) и format!() (который внутри делает unwrap и expect). Но ты пишешь не об этом.

В общем, раскрой мысль (обе), а то ничего не понятно.

А что с ним не так?

То, что между разными типами может быть гораздо больше одного способа преобразования. Например, между целочисленными и IEEE754. Пойди угадай, что там: floor, trunc или round? Или, например, преобразование из 754 в Bool. Как оно с NaN будет работать? А хз. Такие штуки должны быть максимально явными, иначе говна не разгребёшь.

И если на этапе написания кода об этом можно ещё задуматься и расставить типы максимально аккуратно, то через пару лет и десяток разработчиков изменений будет достаточно, чтобы говно где-то точно вылезло.

Ещё вездесущий .unwrap(), на использование которого библиотека просто толкает и пинает

Каким образом?

Отсутствием более удобных средств работы с ошибками кроме Result<>. В условиях, когда нет нормальных исключений, получается то что получается. У меня тут есть пара софтин на Rust, которые регулярно падают, потому что внутри какой-то библиотеки (даже не самой софтины!) сработал panic!() при ошибке в .unwrap(). Представь, как если бы каждая вторая сишная либа в случае, если не смогла что-то нормально обработать, дёргала abort(). Вот это из той же серии.

А вообще, возьми как-нибудь среднюю прогу на Rust и просто посмотри сколько раз там unwrap() дёргается. Каждый этот unwrap() – это потенциальный panic!() в случае, если инварианты изменятся и говнокодер забудет добавить проверку (а он забудет!).

Например, между целочисленными и IEEE754. Пойди угадай, что там: floor, trunc или round?

Никакой из них? the trait From<f32> is not implemented for i32

unwrap() – это потенциальный panic!() в случае, если инварианты изменятся

А чем исключения лучше в этом случае? Инвариант нарушился, исключение поймали в корне программы, и что дальше?

Например, между целочисленными и IEEE754. Пойди угадай, что там: floor, trunc или round? Или, например, преобразование из 754 в Bool. Как оно с NaN будет работать? А хз. Такие штуки должны быть максимально явными, иначе говна не разгребёшь.

Сначала я тебе поверил, а по факту From<fXX> ни для iXX, ни для bool не существует. В мане даже написано явно:

# When to implement From

- The conversion is lossless: semantically, it should not lose or discard information <...>
- The conversion is obvious: it’s the only reasonable conversion between the two types <...>

Отсутствием более удобных средств работы с ошибками кроме Result<>. В условиях, когда нет нормальных исключений, получается то что получается. У меня тут есть пара софтин на Rust, которые регулярно падают, потому что внутри какой-то библиотеки (даже не самой софтины!) сработал panic!() при ошибке в .unwrap().

Я бы тоже хотел, чтобы в расте были исключения (а ещё ABI-resilient динамическая компоновка и чуть более умные генерики, чем через мономорфизацию на каждый чих), но индустрия порешала за меня. А как надо-то? Я уже как-то говорил тебе, что говнокод можно написать на любом языке.

Представь, как если бы каждая вторая сишная либа в случае, если не смогла что-то нормально обработать, дёргала abort(). Вот это из той же серии.

Ну да, вместо этого каждая вторая сишная либа просто забивает :)

Мне кажется, или в коде на расте в среднем больше потенциальных мест паники, чем в коде на Си, сугубо потому что в коде на расте в среднем больше проверок, чем в коде на Си?

Сначала я тебе поверил, а по фактуFrom<fXX>ни для iXX, ни для bool не существует.

Окей, принято. Там в обратном направлении есть, что тоже очень странная штука. Ну и type tetris никто не отменял, когда чуваки пихают десяток вызовов .into() просто чтобы типы сошлись.

А как надо-то? Я уже как-то говорил тебе, что говнокод можно написать на любом языке.

Да, это любимая сишная мантра: си – не плохой язык, вы просто неправильно его держите. Надо просто писать хороший код, а плохой писать не надо.

Ну да, вместо этого каждая вторая сишная либа просто забивает :)

Я не уверен. Это было бы чревато сегфолтом в аналогичной ситуации, а такое случается реже. Прозреваю, что годы порчи памяти и сегфолтов таки научили хотя бы часть сишников не срать себе в штаны. Чувакам с Rust это ещё только предстоит.

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

unwrap() – это потенциальный panic!() в случае, если инварианты изменятся

А чем исключения лучше в этом случае? Инвариант нарушился, исключение поймали в корне программы, и что дальше?

Всем. Особенно если это библиотека. Код в библиотеке вообще никогда не должен вызывать abort()/panic!()/подобную хероту.

а это panic::catch_unwind не помогло? он вроде ловит анврапы

а это panic::catch_unwind не помогло? он вроде ловит анврапы

1. Это костыль и его использовать не рекомендуют;
2. Проще библиотеку поправить, благо впопенсорц;
3. Я тут пользователь, а не разработчик. Но наблюдать стектрейс в консоли от panic!() не в самой проге, а внутри одной из библиотек, всё равно не слишком приятно.

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

А вот это я проглядел. From<bool> for fXX — это максимально всрато и по требованию «conversion is obvious» очевидно не проходит.

Это было бы чревато сегфолтом в аналогичной ситуации, а такое случается реже. Прозреваю, что годы порчи памяти и сегфолтов таки научили хотя бы часть сишников не срать себе в штаны. Чувакам с Rust это ещё только предстоит.

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

Справедливо. Ну да, это теперь жс для нитакусиков.

растамакаками

макаки пишут на js, на rust пишут растаманы

Справедливо. Ну да, это теперь жс для нитакусиков.

Честно говоря, я бы unwrap() для значений, полученных в рантайме, вообще нахрен запретил за пределами unsafe{}. Потому что это почти наверняка паника. Какой-нибудь "127.0.0.1".parse().unwrap() – это окей, особенно если компилятор выполнит это при сборке. Но если значение приходит извне во время работы программы, за такое надо по яйцам бить.

А вообще, возьми как-нибудь среднюю прогу на Rust

Где вы их берете и главное зачем, эти проги на Rust?) Я что-то потребности в них не ощущаю, неужели что-то годное написали и нужное, а не фофановское, как обычно? Ну, ладно, в фуррифоксе, говорят, есть что-то на Расте, и я даже могу придраться, что он падает временами. Но он и раньше падал, не могу сказать, что это стало происходить часто или даже чаще.

Я бы не сказал, что порог вхождения в C или C++ когда-либо был особенно высок.

Там просто сразу за порогом гибнут от голода и жажды с простреленными ногами, выживают только любители садомазо и хрестоматийные маресьевы :D.

Где вы их берете и главное зачем, эти проги на Rust?)

Из репозитариев дистрибутива. Потому что иногда мальчикам требуется запустить программу, чтобы она сделала за них что-то, и иногда эта программа написана на отличном от C или C++ языке программирования.

Я считаю, это возмутительно!

Драйвер то в итоге заработал?