into_rust() — скринкасты по Rust. Доступно видео с RustConf 2016.

Что-то не так с этим языком

По моей теории, с языком-то может и всё так (если действительно кому-то нужно писать какую-нибудь bare-metal low-latency hard-realtime питушню, может он и годен). Но таких задач на типичного пионера не хватает, поэтому раст-коммьюнити в свободное время кормит /всех/ ^____~

Да тут скорее народ общается своеобразно. asaw не понимает половины сказанного, но мнение имеет. eao197 понимает, но пишет так что не понимают его. tailgunner всё понимает, но старается ничего не выболтать. Информации в треде чуть, а жуется который день...

Да тут скорее народ общается своеобразно. asaw не понимает половины сказанного, но мнение имеет.

Скорее «мнение имеют» те, кто не воспринимает моих аргументов, но при этом упорно продолжает утверждать, что Rust - объектно-ориентированный язык.

tailgunner всё понимает, но старается ничего не выболтать

Тебе скажу, как родному - у Rust 2 проблемы: структуры данных, для которых не подходит семантика unique_ptr, и fn вместо fun для определения функций.

Что-то не так с этим языком :|

С планетой языком всё в порядке. Просто у некоторых стало припекать, что их монстр на все времена и правда съедет с пьедестала. Вот они усиленно и убеждают себя, что это не так, а все, кто не с ними, те - неадекваты.

fn вместо fun для определения функций

Спасибо, что поделились с нами вашими личными хотелками. Не прекращайте держать на в курсе. :)

По первому пункту разногласий нет? Прекрасно.

Спасибо, что поделились с нами вашими личными хотелками.

Я знаю, что это важно для вас!

Не прекращайте держать на в курсе. :)

Обещаю.

По первому пункту разногласий нет?

Войдите, пожалуйста, под своей учёткой, товарищ Сталин.

Ты не согласен с линией партии? И список возражений... где?

Что-то не так с этим языком

Людям он интересен, в отличии от.

когда человек пишет Rust - говно, и следом говорит что для железок использует Си, а для сети Go, то варианта может быть всего два: либо человек на самом деле плохо знает Си, Go и Rust, либо это неадекват в терминальной стадии.

... и тема вышла в топ на первое место, сместив прежнюю тему про Rust. Что-то не так с этим языком :|

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

Да и развитие непонятно, некоторые вещи разработчики почему-то не хотят реализовывать.

Ну вот для меня не понятно.

Ну я описал конкретную ситуацию, вызванную определёнными соглашениями, на общность не претендую: хочется явно видеть на ревью наличие или отсутствие обработки потенциальных проблем. Да, это не совсем проблема исключений, скорее они тут просто не подходят и правильнее было бы использовать аналоги Option/Result. Другое дело, что в других местах исключения, вроде как, удобны, а код общий. Можно, конечно, пенять на недостаток дисциплины, но уровень команды, как по мне, весьма неплохой, тем не менее, код в духе «подстрахуемся и кинем тут исключение - когда выстрелит, тогда и будем фиксить» множился.

Формально, с exception safety всё (условно) хорошо, плохо с несоответствием требованиям.

А можно подробнее? А то я не могу себе представить о чем речь.

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

Договориться о том, что именно является «исключительной ситуацией» тоже не всегда удаётся.

Вы путаетесь в показаниях.

И? Я не в ответе за других людей, более того, сам тоже могу заблуждаться.

В C++ же насчет исключений есть четкие гарантии.

Насколько я знаю, в расте всё примерно так же. В смысле, перехватить можно, но паника в «деструкторе» вызванным из-за паники, точно так же как в С++, прибьёт приложение.

Ну и есть возможность самому (в бинаре, а не либе, если что) задавать политику обработки паники: дефолтный вариант - это размотка стеков, вызов деструкторов и возможность перехватить, но можно и выбрать вариант с моментальным терминейтом.

Впрочем, коды возврата (unwrap + catch на панику) тоже удобны для последнего случая :)

Хотел поспорить аргументировав тем, что панику в расте обрабатывать менее удобно, хотя для игнорирования любых проблем это и правда «не проблема».

Но в языке (библиотеке) хотя бы имеются вещи типа «отравления» мьютексов - может оно хоть в какой-то мере препятствовать будет.

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

и fn вместо fun для определения функций.

Какие-то полумеры, только function, только хардкор.

некоторые вещи разработчики почему-то не хотят реализовывать.

Например?

Он сам не знает, просто надо чтобы было.

Он сам не знает, просто надо чтобы было.

Ну почему, мне некоторых вещей тоже не хватает. Например, банальных именованных и опциональных параметров. И как по мне, зря с этим тянут: люди вынуждены дурацкие билдеры делать или прибегать к (некрасивым) трюкам с Option. Тем не менее, «какие-то» причины у такой медлительность есть.

Насколько я знаю, в расте всё примерно так же.

«Примерно так же» это как? Есть четкие гарантии, но не всегда - так что ли? А когда случается это «не всегда» - где нибудь исчерпывающе написано?

В смысле, перехватить можно, но паника в «деструкторе» вызванным из-за паники, точно так же как в С++, прибьёт приложение.

Ну да, когда поника реализуется в виде подобия исключения C++ (как авторы сами же не стесняясь и пишут), то и поведение такое же. Только в C++ есть std::uncaught_exception/std::uncaught_exceptions, std::current_exception, std::rethrow_exception и эту ситуацию тоже, в принципе, можно корректно обработать. В расте же ничего этого нет, а паника - «исключение» неопределенного типа, да и то не всегда.

Он сам не знает, просто надо чтобы было.

Было в прошлом треде.

" Видимо, ваше знание Rust-а намного лучше моего. Я, например, полагал, что если в модуле m1 есть структура S, а в модуле m2 — трейт T, то Вася Пупкин в модуле m3 может сделать свою имплементацию T для S. "

Оказалось нельзя.

Наследования то же нельзя.

Эм... ну как-то так.

«Примерно так же» это как?

Выше я всё описал, что именно не понятно?

Только в C++ есть std::uncaught_exception/std::uncaught_exceptions, std::current_exception, std::rethrow_exception

Ну как есть, uncaught_exceptions - это С++17, не так ли? И я не удивлюсь, если это часть стандартной библиотеки ещё будут дорабатывать. Ну и серьёзно - часто тебе этим пользоваться приходилось? Или хотя бы видеть применение на практике?

Аналог std::uncaught_exception в расте есть, как и некоторые другие способы работать с паникой. У паники слегка другая семантика предполагается, так что не удивительно, что и интерфейс по работе с ней отличается.

«исключение» неопределенного типа, да и то не всегда.

Это как?

Какие-то полумеры, только function, только хардкор.

Нет, уж. Да здравствуют мазохисты-некрофилы! Только declare sub, никаких возражений!

Оказалось нельзя.

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

хотя и не смогу привести действительно важных аргументов.

Это потому что поле непахано. Интуиция подсказывает что тут неплохо развернуться можно, а они не считают нужным. :(

Выше я всё описал, что именно не понятно?

Что ты там описал? «Насколько я знаю» - это весь твой исчерпывающий перечень?

Ну как есть, uncaught_exceptions - это С++17, не так ли?

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

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

Неизвестно какая семантика, зато реализация как у исключений, и использование, как ты сам же и признался, такое же.

Это как?

В C++ у исключений есть тип и ловить их можно не только с помощью catch(...){}. А в расте паника может даже и не быть этим подобием исключения.

Все это в процессе.

Интуиция подсказывает что тут неплохо развернуться можно, а они не считают нужным. :(

Ну развернуться много куда можно. (:

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

И без этой фичи вполне можно прожить. Более того: её, по идее, можно ввести потом без поломки совместимости.

«Насколько я знаю» - это весь твой исчерпывающий перечень?

Да, исчерпывающий. Конкретные возражения есть?

Прямо сейчас есть uncaught_exception и этого, в принципе, достаточно...

...чтобы неправильно обрабатывать некоторые ситуации, ага.

и использование, как ты сам же и признался, такое же.

Ты что наркоман? Где я в таком признавался? На данный момент, сложившаяся практика - не использовать панику для обработки ошибок.

Про реализацию ты опять врёшь - тут есть нюансы.

А в расте паника может даже и не быть этим подобием исключения.

Ещё раз: это как? Покажи мне в расте панику у которой «нет типа».

Ты что наркоман? Где я в таком признавался? На данный момент, сложившаяся практика - не использовать панику для обработки ошибок.

Вот тут вот ты признался: into_rust() — скринкасты по Rust. Доступно видео с RustConf 2016. (комментарий) Или просто ляпнул не подумав?

Про реализацию ты опять врёшь - тут есть нюансы.

Я ничего не вру, излагаю то, что об этом пишут авторы («Panics in Rust are currently implemented essentially as a C++ exception under the hood»), вот и всё, а ты не знаешь.

А в расте паника может даже и не быть этим подобием исключения.

Ещё раз: это как?

Вот ты мне и ответь как это:

«A panic in Rust is not always implemented via unwinding, but can be implemented by aborting the process as well. »

Перечисли мне эти случаи когда конкретно «can be», а когда - нет.

Перечисли мне эти случаи когда конкретно «can be», а когда - нет.

• Паника в Drop про панике.
• Программа собрана с panic=abort
• Паника внутри abort_on_panic!()
• Паника через границу ffi (c-библиотека, кинула SIGILL, например)

Вот тут вот ты признался

Не вижу по ссылке ничего похожего на «паники используются точно так же, как исключения». Похоже, что ляпает кто-то другой.

вот и всё, а ты не знаешь.

Опять в лужу сел. Поведение паники может настраиваться.

«A panic in Rust is not always implemented via unwinding, but can be implemented by aborting the process as well. »

Так я об этом и говорил выше: есть опция panic, которая может принимать значения unwind или abort. В последнем случае никакой размотки не будет: аналог (нестандартной) опции -fno-exceptions. Тип у паники при этом никуда не пропадает, меняется поведение. Кстати, куда идут все твои «плюсовые гарантии» при использовании этой опции?..

Паника в Drop про панике.

Не соглашусь: паника в этом случае всё равно будет реализована через размотку, просто этот процесс прерывается в данном «специальном случае». Ровно так же, как и в плюсах.

Паника через границу ffi (c-библиотека, кинула SIGILL, например)

Так ведь это будет вообще не паника?..

Паника внутри abort_on_panic!()

Это мало чем отличается от вызова простой функции, которая внутри abort дёргает.

хочется явно видеть на ревью наличие или отсутствие обработки потенциальных проблем.

Похоже, вы хотите видеть что-то вроде checked exceptions из Java: если метод f() может кинуть исключение E, то это должно быть видно из сигнатуры.

Проблема только в том, что даже в Java это не до конца заработало, там есть еще и unchecked exceptions и этим пользуются.

Да и в Rust-е может быть Result<SomeType, Error>, где за Error прячется целая куча типов, реализующих интерфейс Error. Причем набор этих типов может пополнятся без постановки в известность клиента.

тем не менее, код в духе «подстрахуемся и кинем тут исключение - когда выстрелит, тогда и будем фиксить» множился.

Так проблемы же здесь не в исключениях, а в том, что либо не хватает времени на проработку, либо не хватает понимания задачи для того, чтобы определить нормальную реакцию и нормальное поведение. (Понимания задачи может не хватать вовсе не из-за уровня участников команды, а из-за новизны предметной области или из-за того, что вообще в команде нет людей, которые бы точно знали «как надо»).

В таких условиях вместо исключений запросто можно брать Result<Type, Error>, а затем плодить и возвращать кучу разных Error-ов, о которых конечный пользователь может даже и не подозревать.

Ровно так же, как и в плюсах.

Я не плюсовик, мне до лампочки, как оно там. :)

Так ведь это будет вообще не паника?..

Это могла бы быть паника (по логике). Но жизни плевать на логику. :) Данная ситуация считается UB, а rust UB не допускает, по этому держите abort и идите гуляйте.

Это мало чем отличается от вызова простой функции, которая внутри abort дёргает.

За исключением того, что внутри может быть вызов panic!(), который не будет пойман.

Я не плюсовик

Если не секрет, с какого языка вы перешли на Rust и почему?

Не вижу по ссылке ничего похожего на «паники используются точно так же, как исключения». Похоже, что ляпает кто-то другой.

Там спрашивалось (не у тебя) чем отличается конкретное использование. Ты написал, что буковками (то есть по сути - ничем). У тебя дислексия что ли?

Опять в лужу сел. Поведение паники может настраиваться.

Иди и скажи авторам ловли паник в расте, что они сели в лужу, умник.

аналог (нестандартной) опции -fno-exceptions. Тип у паники при этом никуда не пропадает, меняется поведение. Кстати, куда идут все твои «плюсовые гарантии» при использовании этой опции?..

Это не аналог того, что ты описал. Иди читай документацию.

Похоже, вы хотите видеть что-то вроде checked exceptions из Java: если метод f() может кинуть исключение E, то это должно быть видно из сигнатуры.

В курсе, но как раз сигнатуры (в полной мере) не помогут, псевдокод:

void foo() throw E {
    // Тут может вылететь исключение E и это нормально и сопровождается комментарием.
    const auto& val = get_value();
    ...
    // Тут тоже может вылететь исключение E и это не нормально, но разработчик провтыкал.
    process(val);
}

Причем набор этих типов может пополнятся без постановки в известность клиента.

Да, но если нас ситуация «или обработали или пробросили дальше», то всё нормально. Явные unwrap будут видны, явное игнорирование - тоже, а случайно проигнорировать не удастся.

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

Для вас, очевидно, круче C++

Очевидно, что так вопрос ставят только неповзрослевшие детишки.

Жаль. Дело вовсе не в разборках и выяснении у кого длиннее. Всегда интересно узнавать причины тех или иных действий у тех, кто эти действия совершил. Обмен опытом и все такое.

За исключением того, что внутри может быть вызов panic!(), который не будет пойман.

Внутри чего?

Ну и я к тому, что аборт и самому позвать можно, грубо говоря:

let result = panic::catch_unwind(|| {
    unsafe { abort(); }
    panic!();
});

Да, частный случай, но и такое случается. И нет я не готов призывать к полному отказу от исключений. (:

Э... И как здесь помогут коды возврата?

fn foo() -> Result<R, Err> {
  let val = try!(get_value()); // Тут E и это нормально.
  ...
  try!(process(val)); // Тут E, но это не нормально, а лопухнулся разработчик.
}

Да, но если нас ситуация «или обработали или пробросили дальше», то всё нормально.

Видимо, здесь у меня такое же недоумение, как и на процитированную выше фразу.

Очевидно, что так вопрос ставят только неповзрослевшие детишки.

*пожал плечами* Что я могу тут поделать, я за других не отвечаю.

Ты написал, что буковками (то есть по сути - ничем). У тебя дислексия что ли?

Скорее у тебя с пониманием. Причём я ведь ответил на твой последующий вопрос. Повторить?.. Ладно: панику можно использовать как (не особо удобную удобную) замену исключениям, но на данный момент, так делать не принято. И с таким использованием я не сталкивался.

И от «буковок» польза очень даже имеется.

Иди и скажи авторам ловли паник в расте, что они сели в лужу, умник.

Аргументов снова нет?

Это не аналог того, что ты описал. Иди читай документацию.

Процитируй. Или только щёки надувать способен?

Чтобы провтыкать в случае исключений, достаточно из process() вызвать что-то выбрасывающее E. В случае с кодами возврата, в process() нужно будет явно пробросить E наверх.

Э... И как здесь помогут коды возврата?

Будет скорее вот так:

fn foo() -> R {
    // Комментарий поясняющий почему тут упасть нормально.
    let val = get_value().unwrap();
    ...
    process(val).unwrap_or(DefaultValue);
}

И нет я не готов призывать к полному отказу от исключений.

Хех, а я вот вожусь с подключением vectored execeptions handling, чтобы задавить исключение, которое забыли подавить разработчики GPU-based validation.

В случае с кодами возврата, в process() нужно будет явно пробросить E наверх.

Что в коде на Rust в массовом порядке делается путем повсеместного использования try!

Так ведь это же прямой путь к паникам, не?

fn foo() -> R {
    // Комментарий поясняющий почему тут упасть нормально.
    let val = get_value().unwrap();