LINUX.ORG.RU

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

 , , ,


7

5

into_rust() — это плод годовой работы Николаса Мацакиса, одного из основных членов команды разработчиков Rust, и представляет из себя хранилище обучающих скринкастов по данному языку программирования. Обучение строится вокруг принципа работы с памятью в Rust: владение и заимствование.

На сайте (на момент написания новости) уже представлены следующие скринкасты:

На будущее запланированы следующие темы:

  • Structs and enums;
  • Threads;
  • Traits;
  • Named lifetime parameters;
  • Aliasing and mutability.

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

Также стали доступны видеозаписи с прошедшей 10 сентября первой конференции по Rust — RustConf 2016.

Для просмотра доступны:

>>> Подробности

★★★★★

Проверено: Shaman007 ()

Ответ на: комментарий от anonymous

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обещаю.

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

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

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

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

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

RazrFalcon ★★★★★ ()

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

JamesMoore ()
Ответ на: комментарий от anonymous

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

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

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

anonymous ()
Ответ на: комментарий от eao197

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

anonymous ()
Ответ на: комментарий от asaw

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

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

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

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

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

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

Это как?

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

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

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

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

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

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

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

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

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

anonymous ()
Ответ на: комментарий от DarkEld3r

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

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

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

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

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

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

Это как?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот тут вот ты признался: 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», а когда - нет.

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

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

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

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

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

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

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

«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. Тип у паники при этом никуда не пропадает, меняется поведение. Кстати, куда идут все твои «плюсовые гарантии» при использовании этой опции?..

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Внутри чего?

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

let result = panic::catch_unwind(|| {
    unsafe { abort(); }
    panic!();
});
Но это, как по мне, не будет иметь никакого отношения к (не)возможности обработать панику.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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