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 ()

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

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

С unwrap() ты не сталкивался??? Но это же очевидное враньё!

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

У тебя нет аргументов, ты же к цитатам авторов цепляешься со своим мнением.

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

User code that uses C++ keywords like throw, try, and catch will produce errors even if the user code has included libstdc++ headers and is using constructs like basic_iostream. Even though the standard library has been transformed, user code may need modification. User code that attempts or expects to do error checking on standard library components compiled with exception handling disabled should be evaluated and potentially made conditional.

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

Началось то с того, что:

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

Я понимаю, если разработчик не прочитает документацию и вызовет функцию, выбрасывающую исключение. Но если он знает, что тут ничего вылетать не должно, и тем не менее меняет сигнатуру process() и пишет try!() вместо unwrap_or, это уже как-то менее понятно.

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

Я воспринял пример DarkEld3r явно иначе, чем вы.

В случае с checked exception если мы имеем:

ret_type a() throw E {...}
ret_type b() throw Y {...}
ret_type foo() throw E {
  auto v = a();
  b();
}
Компилятор ударит по рукам, т.к. b() может бросать Y, но в сигнатуре foo() это не отражено. Поэтому разработчик либо должен расширить сигнатуру foo(), либо должен перехватывать исключение Y при вызове b().

Однако, если мы имеем:

ret_type a() throw E {...}
ret_type b() throw E {...}
ret_type foo() throw E {
  auto v = a();
  b();
}
То компилятор не даст по рукам, т.к. и a() и b() бросают E. Разработчик же об исключении из b() может забыть.

Аналогично, в Rust-е мы можем имеет что-то вроде:

fn a() -> Result<R, E> {...}
fn b() -> Result<R, E> {...}
fn foo() -> Result<R, E> {
  let v = try!(a());
  let v2 = try!(b());
  ..
}
И компилятор никак не подскажет, что в месте вызова b() какой-то конкретный тип ошибки должен восприниматься как фатальная проблема и обрабатываться как-то иначе.

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

Извиняюсь, не сообразил, что в примере использовался псевдо-С++ с checked-exceptions, а не throw-спецификации из какой-то версии С++.

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

Внутри чего?

Внутри макроса. Там вы можете вызывать методы, которые могут бросить панику.

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

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

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

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

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

Согласен, хороший вопрос.

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

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

Не уверен, что это можно считать аргументом. (:

Или думаешь, что с паникой такого не могло бы быть?

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

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

Да, но это устраивает. В общем, это (вероятно частный) случай когда логика паник очень удачно ложиться: почти все проблемы надо обрабатывать, но некоторые считаются «совсем фатальными».

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

С unwrap() ты не сталкивался??? Но это же очевидное враньё!

Ты издеваешься? Не сталкивался с применением паники «вместо исключений». То есть, с построением логики на перехвате паники и, тем более, на перехвате паники с разными вариантами обработки, в зависимости от типа.

У тебя нет аргументов, ты же к цитатам авторов цепляешься со своим мнением.

Давай ты нормально претензии озвучишь. Пока что это похоже на какой-то абсурд: я не спорю с тем, что «паника реализована как исключения», но только при panic=unwind, что не является единственным доступным вариантом.

User code that uses C++ keywords like throw, try, and catch will produce errors

Ок, я был не прав.

Тем не менее, исключение может быть выброшено из библиотеки.

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

Да это и не аргумент был. К слову пришлось. С документацией к SEH, кстати, какая-то ерунда. На MSDN ничего полезного кроме бесполезных __try, __except поиском не находится. Гугл находит какую-то древнюю статью, предлагающую работать через fs:[0]. Я уже и растовским инлайн ассеблером успел побаловаться (удобно), пока нормальное API нашёл.

Ладно. Оффтопик.

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

У нее внутри Box<StdError>.

Box<StdError> - это предыдущая ошибка.

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

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

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

Речь была о:

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

В error-chain ничего не плодят и не возвращают. Вернее, там плодят варианты ErrorKind'а и мапят в них чужие ошибки, а речь была о возвращении из функции разных ошибок в виде Box<Error>.

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

В error-chain ничего не плодят и не возвращают. Вернее, там плодят варианты ErrorKind'а и мапят в них чужие ошибки, а речь была о возвращении из функции разных ошибок в виде Box<Error>.

В error-chain именно возвращают чужие ошибки в виде Box<Error>.

http://rust-lang-nursery.github.io/rustup.rs/error_chain/index.html#chaining-...

" If the Result is an Err then chain_err evaluates the closure, which returns some type that can be converted to ErrorKind, boxes the original error to store as the cause, then returns a new error containing the original error"

Больше никак чейнинг и не реализовать.

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

а для embedded...

а для embedded, по большей части, это как раз и есть состояние «всё, приехали» и срабатывает паника. Результат которой, обычно, для дебаг сборок - диагностическая информация, а для продакшена - ребут («быстро поднятое, упавшим не считается»).

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

Ну почему? Можно и муху у себя на лбу прихлопнуть.

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

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

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

Мне, как пользователю, твои трейсы не нужны.

Они тебе понадобятся, если придётся вступить в контакт с техподдержкой/разработчиком.

В обоих случаях я скажу, что разработчик идиот.

Людям свойственно ошибаться. Идиоты - те, кто этого не понимает.

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

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

red75prim ★★ ()

Сишники послали растовцев c их натянутыми проблемами, так теперь они стали заказывать статьи вида Rust vs Java?? Rust 1.7 (комментарий)

Даааа, это прям мечта джависта, язык почти такой же производительности (и жруший столько же памяти), но при этом теперь тебе на халяву нужно страдать с лайфтаймами, с компилятором и гибридно-испорченным синтаксисом из ФП Причем там даже не завезли инкапсуляцию (сколько веселья то для промышленного кода)?

Это успех я считаю

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

Причем там даже не завезли инкапсуляцию

Что, опять?

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