LINUX.ORG.RU

Rust 1.9

 


0

3

Анонсирована очередная версия языка программирования Rust 1.9, разрабатываемого Mozilla совместно с сообществом. Примечательно то, что с момента релиза первого стабильного выпуска прошел 1 год.

Основные изменения:

  • Стабилизирован модуль std::panic, позволяющий перехватывать раскрутку стека. Соответствующие функции рекомендуется применять только в исключительных ситуациях, но никак не для эмуляции механизма try-catch.
  • Стабилизированы методы настройки TCP и UDP соединений; расширены возможности OsString, BTreeSet и HashSet; char может быть получен из UTF-16 последовательности; стабилизирована функция copy_from_slice(); появилась возможность работы с волатильными переменными с помощью read_volatile и write_volatile; сырые указатели обрели .as_ref() и .as_mut(), которые возвращают Option<&T>, где null будет представлен как None; в libcore для всех типов реализован Debug.
  • Разработчикам библиотек доступен атрибут #[deprecated], разрешающий компилятору слать предупреждения при использовании устаревшего API.
  • Специализация уже используется в ночном релизе и будет доступна в стабильном 1.11 через 3 месяца, но оптимизация .to_owned() и .to_string() таки попала в текущий стабильный выпуск.
  • Расширен список поддерживаемых платформ: mips-unknown-linux-musl, mipsel-unknown-linux-musl, i586-pc-windows-msvc.
  • Ускорено время компиляции монады с одинаковыми функциями.

Изменения в менеджере зависимостей Cargo:

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

Для кросс-компиляции подготовлен инструмент rustup, обеспечивающий тривиальное взаимодействие с каналами сборок компилятора (stable, beta, nightly), стандартными библиотеками и их документацией к различным операционным системам, а также обновление всего этого зоопарка одной командой.

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



Проверено: Falcon-peregrinus ()
Последнее исправление: shaiZaigh (всего исправлений: 2)
Ответ на: комментарий от conformist

думал rust — передовые технологии и его уже используют везде, где только можно.

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

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

Т.е. это рекомендация исходя из религиозных соображений, а не технических?

Ну да. Если совсем такую функциональность не давать, то в ряде случаев будет «неудобно». Так что остаётся только «делать рекомендации».

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

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

По факту, определённая поддержка в них всё равно есть.

Начинать спор о пользе или вреде исключений не хочу.

DarkEld3r ★★★★★
()

Слишком хипстерки. Ada и FORTH лучше.

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

Это неудобно. Исключения гораздо более удобный механизм для обработки ошибок

Это неудобно, если алгебраических типов нет. В Rust'е, в месте ошибки возвращаем Err(MyError), выше по стеку пишем try!, где надо обработать делаем match.

red75prim ★★★
()

О круто! Я недавно ковырял его - написал «синтезатор речи»)))

http://pheodor.crabdance.com

https://github.com/truefedex/chatterbox

Оно «синтезирует» моим голосом (по-сути просто складывает предзаписанные звуки). Крутится у меня на домашнем Raspberry PI. Для Rust уже веб фреймворки есть, даже несколько - я использовал Iron.

FedeX ★★
()
Последнее исправление: FedeX (всего исправлений: 1)

Язык говно и ничего нового-удобного не принес.

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

И програма аварийно завершается?

нет - передает ошибку выше по стеку либо, если ошибки нет, продолжает выполнение.

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

Это неудобно.

Это вполне удобно при развитых языковых конструкциях. Сейчас есть `try!`, в будущем будет https://github.com/rust-lang/rust/issues/31436
Ошибка это значение, а не какой-то странный зверь что раскручивает стек.

quantum-troll ★★★★★
()
Ответ на: комментарий от Legioner

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

В большинстве случаев. Способ падения выбирается автором крейта, по умолчанию раскрутка стека.

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

Да ничего, в принципе, отличного и нет. Иллюзия безопасности, разве только.

Ну и синтаксис еще более упоротый чем крестовые шаблоны александреску

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

А как этот язычок, по сравнению с C (C11)?

Как танк по сравнению с инвалидной коляской.

Знаю, что фигню спрашиваю.

Не стану даже спрашивать, на какой ответ ты рассчитываешь :)

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

Как гораздо менее монстроуозный С++ с приятными фичами современных языков.
Если ты из тех сишников, что кричат «НИНУЖНО» на шаблоны/генерики, то раст тебя вряд ли заинтересует. Иначе смотри сам.

quantum-troll ★★★★★
()

Соответствующие функции рекомендуется применять только в исключительных ситуациях, но никак не для эмуляции механизма try-catch.

Именно в исключительных ситуациях его и будут использовать, честно честно!

Ну и

Rust does not currently have a rigorously and formally defined memory model, so the precise semantics of what «volatile» means here is subject to change over time.

Тоже очень порадовало.

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

в месте ошибки возвращаем Err(MyError), выше по стеку пишем try!, где надо обработать делаем match.

Это я и называю неудобно. Менять типы всех функций, каждый вызов оборачивать в try!. Не особо отличается от С, разве что деструкторы сами запускаются.э

Единственный юзабельный вариант, который я вижу — если компилятор будет сам всё это делать (менять возвращаемый тип, ставить проверки при каждом вызове). Но этого нет.

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

В большинстве случаев. Способ падения выбирается автором крейта, по умолчанию раскрутка стека.

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

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

Я про реальные и полезные тулзы.

На офф сайте имеется страница со списком организаций, использующих раст в продакшене.

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

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

quantum-troll ★★★★★
()

Стабилизирован модуль std::panic

Made my day!

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

Единственный юзабельный вариант, который я вижу — если компилятор будет сам всё это делать

А смысл? От исключений уходят ради «большей явности» и лучшей (само)документированности кода - по сигнатуре видно какие проблемы могут возникнуть. Если это будет делать компилятор автоматически, то чем оно от исключений отличаться будет?

Кстати, в Swift сделали нечто похожее на то, что ты хочешь, но как по мне, это худшее из двух миров: промежуточный код должен знать о том, что может возникнуть ошибка («как в расте»), но какая именно не видно (как с исключениями).

P.S. Раньше я всегда в таких спорах был за исключения.

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

А смысл? От исключений уходят ради «большей явности» и лучшей (само)документированности кода - по сигнатуре видно какие проблемы могут возникнуть.

Я не вижу смысла в этой информации — какие проблемы могут возникнуть. Когда я пишу функцию, которая выполняет SQL-запрос, я не собираюсь думать о том, что у меня может выпасть сетевой кабель, сервер БД может уйти в перезагрузку, пьяная обезьяна может удалить таблицу и тд. Мне всё это совершенно неинтересно. Мне даже не интересен в принципе случай, когда SQL-запрос может не выполниться. Я живу в волшебном мире, в котором этот SQL-запрос всегда выполняется успешно и я думаю о том, что мне делать с его результатами. Я не против того, чтобы эта информация была, пусть в IDE будет кнопочка «показать все возможные исключения, которые могут вылететь из этой функции», в принципе это всё статически выводится.

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

Этот подход позволяет писать чистый и понятный код в 99% случаев. По крайней мере в программах, которые я пишу. Допускаю, что есть программы, в которых этот подход хуже, чем явные проверки на каждый чих. Я с ними не сталкивался. Мне очень сложно вспомнить какие-либо случаи, когда я бы хотел обработать исключительную ситуацию. Это тот самый 1% и писать весь код для него я считаю глупостью.

Если это будет делать компилятор автоматически, то чем оно от исключений отличаться будет?

Не знаю, видимо ничем. Разве что тормозить будет чуть больше.

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

Открыл файл, начал что-то с ним делать, и тут прилетело говно из библиотеки. кто будет думать о том что файл нужно закрыть? код выше по стеку? а если два файла? а если три? такое, что, только в 1% кода встречается?

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

Когда я пишу функцию, которая выполняет SQL-запрос, я не собираюсь думать о том, что у меня может выпасть сетевой кабель, сервер БД может уйти в перезагрузку, пьяная обезьяна может удалить таблицу и тд

Существуют разные уровни абстракции.

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

в принципе это всё статически выводится.

В плюсах не выводится, например.

Но вообще мысль понятна и я даже в какой-то степени согласен. Сильно ввязываться в спор не хочу так как тоже считаю исключения (пусть и не во всех случаях) удобными. Близком к идеальному мне видится подход С++ в стандартной библиотеке - (почти) везде исключения опциональны, да и вообще их мало. При этом сам механизм присутствует и позволяет самостоятельно выбирать стратегию. Другое дело, что при написании библиотек не всё так просто.

Опять же, уход от исключений - это стремление дать «больше гарантий». Исключение можно (и очень легко) забыть обработать везде где необходимо. Если нас устраивает, что обработка будет добавляться по мере тестирования/использования, то и правда «всё хорошо».

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

кто будет думать о том что файл нужно закрыть?

Деструктор?

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

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

Деструктор или try-finally блок или try-with-resources блок. Это не проблема.

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

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

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

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

Как танк по сравнению с инвалидной коляской.

как?

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

Dropbox Infra is mostly a Go shop.

Т.е., по сути, это мелочи для rust

То есть компонент, который по сути является ядром бизнеса Dropbox, написан на Rust.

О как! В оригинале немного не так:

Actually, full disclosure, we really just rewrote a couple of components in Rust. Most of Magic Pocket (the distributed storage system) is still written in golang.

Тебе перевести на велико-могучий или сам осилишь?

Впрочем справедливости ради оно вообще всё на питоне было. Так что если ещё раз перепишут но на ржавчине - я не сильно удивлюсь. Но тут такое дело: python->go профит увидели даже слепые, go->rust ... не ну Ынженеры покажут достоверные графики на сколько процентов оно всё таки получшало :)

anonymous
()

На расте возможно программирование микроконтроллеров? Какие компиляторы есть, для каких платформ? Он способен полностью заменить Си? Стандартная библиотека считается частью языка?

Какие цели преследовала Мозилла начиная проект Раст? Чётко ответьте, только без воды?

anonymous
()

Примечательно то, что с момента релиза первого стабильного выпуска прошел 1 год.

Если это единственная примечательная вещь, то все грустно.

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

На расте возможно программирование микроконтроллеров?

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

Стандартная библиотека считается частью языка?

считается стандартной библиотекой

Мозилла начиная проект Раст?

Не она начала вовсе, только подхватила. Но хз, насколько он ей нужен.

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

На расте возможно программирование микроконтроллеров? Какие компиляторы есть, для каких платформ? Он способен полностью заменить Си?

А мне вот интересно, какие цели преследуют ярые «заменяторы Си»?!

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

Rust does not currently have a rigorously and formally defined memory model, so the precise semantics of what «volatile» means here is subject to change over time.

Версия один-девять, господа!

В C появилась только в C11 и успела собрать свою порцию критики. В C11, господа!

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

Тогда просто спрошу — стоит ли изучать rust?

Если возникает такой вопрос - то точно не нужно. Не факт еще, что получит популярность.

Вот те, для кого понятие «изучать ЯП» стоит где-то недалеко от «изучать MS Office», могут попробовать.

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

Удобно писать веб, решения для прикладных задач, наколенные прототипы и тому подобные «несерьёзные» вещи, которых большинство. Считай, как компилируемый Питон с типизацией. «Матёрые» «системные» «программисты», конечно, плюются, но это они не со зла а просто от когнитивной ригидности.

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