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)
Ответ на: комментарий от RazrFalcon

Реализация fold есть в сорцах rust - так и реализовал бы. Коды ошибок тут не нужны. Здесь нечему падать. А если и было бы чему - я бы написал развернутую версию на циклах.

Писать развёрнутую функцию не обязательно - ведь в качестве начального значения можно подсунуть Option/Result и соответственно вернуть не просто значение, а и ошибку.

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

Если я тебя правильно понял:

Зачем этот ужас? В стандартный fold уже можно передать Result и вернуть ошибку, если есть необходимость.

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

Зачем этот ужас? В стандартный fold уже можно передать Result и вернуть ошибку, если есть необходимость.

См. это и выше по треду.

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

Ну я даже не представляю, как бы в Rust выглядели unchecked exceptions.

А чего тут представлять? panic! вместо throw, catch_unwind вместо catch.

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

2-3 типа ошибок. Тип ошибок - это один sum type на крейт.

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

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

Настало время УДИВИТЕЛЬНЫХ историй:

За год с релиза ничего не сломали. За обратной совместимостью строго следят.

Одна история УДИВИТЕЛЬНЕЙ другой: раз, два, три и так далее...

БЕСПРЕЦЕДЕНТНО следят за совместимостью! В каждом минорном релизе ломают!

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

И? Вы почитайте эти предупреждения. Там мелочи. Я свой, небольшой, проект протащил с 1.5 до 1.9 без единой правки сорцов.

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

Используется на уровне два других крейта и нужно из них прокидывать некоторые ошибки выше - что делаем?

Именно прокидывать ванильные ошибки нижних крейтов? Добавляем в sum type ошибок варианты для ошибок используемых крейтов или один Any для них всех.

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

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

То это мало чем отличается от:

Ну «маленькое» отличие всё-таки есть: в расте не получится забыть обработать ошибку. Игнорирование тоже придётся делать явно.

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

Да пишите на чем хотите! Я не пойму, в чем проблема?!

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

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

Грустно наблюдать, что Rust начинает обрастать легаси. Сейчас из-за специализации `to_string()` vs `to_owned()`, потом будет `try!` vs `?` и т.д.

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

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

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

И чем это будет отличаться от использования Result как в расте?

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

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

У меня тоже проблем с поломанной совместимостью не было. Только 2-3 раза фичи из nightly приходилось фиксить. Проект около 20kLoC.

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

Но его исключения похожи на сахар над растовским Result.

Как по мне, так это ни туда ни сюда. Имеем минусы исключений в том плане, что из сигнатуры не видны конкретные ошибки и минусы Result - по всему стеку вызовов надо делать пометки о том, что ошибки всё-таки могут быть. Этакий noexcept получается.

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

стоит ли учить Go, есть ли для него биндинги wxWidgets/gtk/Qt?

Я Go не пользуюсь, так что (неправильные) советы давать остерегусь.

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

Swift 2.0

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

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

За год с релиза ничего не сломали. За обратной совместимостью строго следят.

Из свеженького: .abs_sub() уже помечен устаревшим, хотя и был стабилизирован в 1.0.

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

Написание кода на rust это борьба с компилятором, даже по сравнению с любым другим статическим языком. Борьба не в том смысле что компилятор проблемный, а в том что сам язык так задуман. Компилятор выдаёт сообщения которые нужно тщательно обдумывать, стараться полностью понять. Одно за другим.

Чем это отличается от haskell?

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

Из свеженького: .abs_sub() уже помечен устаревшим

Но это ведь ещё не поломка?

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

Там мелочи.

ЯСНО @ ПОНЯТНО Молодой человек, а вы слышали, что у солидных господ не принято ломать обратную совместимость в минорщине после версии 1.0.0?

Тут, как говорится, «либо крестик сними, либо трусы надень!»

А если уж ты «под давлением маркетолухов» сделал 1.0.0, то будь добр, при поломке обратной совместимости, делать мажорный релиз.

Я свой, небольшой, проект протащил с 1.5 до 1.9 без единой правки сорцов.

Ага, а я свой небольшой проект могу скомпилировать как компилятором Си та и компилятором СиПлюсПлюс!

Без ошибок! Даже варнингов не будет!

Но при этом всем известно, что в плюсах «обратная совместимоть» поломана.

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

Что разработчики Rust из чисто «маркетинговых» соображений выпустили сырую бету вместо полноценного релиза. А потом устроили анальную клоунаду с поломкой обратной совместимости в каждом минорном релизе.

В каждом, Карл, минорном, Карл!

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

За то гламурные геи не пытаются стыдливо прикрыть Breaking Changes с помощью Compatibility Notes.

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

Кто-нибудь, зарепортите этого озорника!

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

Go, есть ли для него биндинги wxWidgets/gtk/Qt?

Если посмотреть проекты на go, то программы с web UI встречаются на порядок чаще чем с обычным gui. ну и текстовых интерфейсов тоже много. Я думаю что это связано с тем что на go обычно пишут ПО для серверов, а также потому что написать на go простой web UI чрезвычайно просто (по сравнению с другими языками).

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

разработчики Rust из чисто «маркетинговых» соображений выпустили сырую бету вместо полноценного релиза

Ну так и говори. А то от твоих потуг на сарказм аж в глазах щиплет.

В каждом, Карл, минорном, Карл!

Обратная совместимость - это не bool, а float. Так что всякие мелочи, конечно, неприятны, но в общем, фигня ничего не значащая.

tailgunner ★★★★★
()

Программист, способный со всем этим разобраться и на крестах ошибок не сделает.

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

А то от твоих потуг на сарказм аж в глазах щиплет.

Тебе НЕПРИЯТНО?

Ты хочешь об этом поговорить?

Обратная совместимость - это не bool, а float.
Так что всякие мелочи, конечно, неприятны, но в общем, фигня ничего не значащая.

Сверхманевренность_вопросы_остаются.пнг Нет, родной, она либо есть, либо ее нет, по определению.

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

Программист, способный со всем этим разобраться и на крестах ошибок не сделает.

Да ладно. Любому дебилу можно объяснить, что такое null, но при этом NPE бывает и в серьёзных проектах.

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

Из свеженького: .abs_sub() уже помечен устаревшим, хотя и был стабилизирован в 1.0.

А как должны были поступить разработчики правильного языка?

Тащить этот .abs_sub() до скончания времён?

Спокойно глотать его вплоть до последнего минорного релиза ветки 1.*, а потом в 2.0 сразу выкинуть, типа раз уж взялись мигрировать на новый мажорный релиз, вот и поработайте?

Подождать, объявить устаревшим в 2.0 и удалить через год в каком-нибудь 2.9, поломав совместимость внутри одной мажорной ветки?

Подождать, объявить устаревшим в 2.0 и удалить в 3.0, тем самым задержав удаление плохого метода на 3-5 лет?

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

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

Ты хочешь в (практически) каждой функции декларировать возможные исключения?

Я хочу иметь возможность:

1. Задекларировать исключение, которое вызывающий код ОБЯЗАН обработать. Даже если он обработает его неправильно, это его проблемы

2. Быть уверенным, что я обработал все исключения, которые задекларированы в нижележащих функциях.

3. Это уже моя хотелка, но вообще говоря, исключения бывают разных типов (по разным причинам) и по уму должны хэндлиться по-разному.

То, что рустовый компилятор проверяет unused в result'е, это конечно хорошо. Вот только обработка разнотипных исключений превращается в лапшу.

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

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

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

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

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

Вот только обработка разнотипных исключений превращается в лапшу.

Ничего не превращается. Код: ... try!(a()); try!(b()); try!(c()); ... отлично обработаются, даже если ошибка у вызываемых функций разная.

Правда, для качественной обработки придётся завести свой тип ошибки и реализовать для него трейты From<EA>, From<EB> и From<EC>, но в общем и целом лапша будет вынесена из собственно функции и на читабельность кода не повлияет. Но и это необязательно, если ошибки реализуют трейт Error, то можно просто возвращать из этой функции Result<T, Box<Error>>, в этом случае никаких трейтов реализовывать не надо, ошибка в Box<Error> сама сконвертится. Хоть и тип эксепшена теряется, но можно вывести текстовое описание и можно посмотреть обёрнутые ошибки. В принципе можно и скомбинировать, завести свой тип ошибки, который оборачивает одни виды ошибок в отдельные варианты, а для остальных реализует вариант OtherError(Box<Error>)

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

Но им не нужна замена в локальном проекте, им нужна замена в мировом масштабе.

Причем до того, как язык стабилизируют.

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

panic! вместо throw

Не рекомендуют же!

catch_unwind вместо catch

Почитал об этом на rust-lang — тоже не рекомендуют. Unstable

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

Добавляем в sum type ошибок варианты для ошибок используемых крейтов или один Any для них всех.

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

... или один Any для них всех.

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

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

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

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

то у ошибок часто бывает иерархия и хочется ловить не листья этой иерархии, а внутренние узлы.

У разработчиков раста принципиальная позиция: наследование и прочее ООП в 95% случаев используется в качестве кривого костыля к отсутствию типов сумм. Вот что это за листья/внутренние узлы иерархии? Что, реально кому-то нужно наследоваться от, скажем, NotSupportedException? Или строить действительно сложную иерархию собственных исключений? В большинстве случаев нужен 1 или 2 уровня детализации. И они отлично реализуются простым типом ошибки с перечислением вариантов, если нужно уточнить.

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

У разработчиков раста принципиальная позиция: наследование и прочее ООП в 95% случаев используется в качестве кривого костыля к отсутствию типов сумм.

Что разработчики раста нашли фатальный недостаток в некоторых фичах других яп и им показалось как же всё должно быть на самом деле вполне очевидно. И более менее ясно в какой заднице они окажутся с политикой решения таких проблем техническим фашизмом.

что, реально кому-то нужно наследоваться от, скажем, NotSupportedException?

Раз сам придумал сценарий, то и объясняй своими силами зачем это нужно. Обычно наследуются от базового исключения типа std::exception и далее делают что требуется.

В большинстве случаев нужен 1 или 2 уровня детализации. И они отлично реализуются простым типом ошибки с перечислением вариантов, если нужно уточнить.

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

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

Раз сам придумал сценарий, то и объясняй своими силами зачем это нужно. Обычно наследуются от базового исключения типа std::exception и далее делают что требуется.

Это был вопрос. «Нужно ли?». Мой ответ - не нужно.

Обычно наследуются от базового исключения типа std::exception и далее делают что требуется.

В расте для этого есть трейт Error.

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

Как не видно? Я прямым текстом написал решение: свой тип ошибки + уточняющее перечисление в нём. Есть, например, в std::io::Error, можно обрабатывать его, а можно вызвать метод kind() и уточнить, что произошло. 2 уровня. В реальности тут даже три уровня, можно преобразовать любую ошибку в trait object (т.е. в указатель на трейт Error), этого достаточно, чтоб распечатать на экране «стек» исключений, можно обработать std::io::Error, можно обработать с уточнением по перечислению std::io::ErrorKind.

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

Читать умеешь? Там топ 25 программных ошибок, ну и где там ошибки работы с памятью?

На основании каких (статистических) данных ты говорил про 90%?

Safe, deterministic memory reclamation is a hard problem, but is not the only problem or even the most important problem in a program.

(С) Александреску

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

Чем моя статистика хуже вашей?

ну и где там ошибки работы с памятью?
CWE-120 Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
CWE-131 Incorrect Calculation of Buffer Size
CWE-134 Uncontrolled Format String (можно отнести к памяти)
CWE-190 Integer Overflow or Wraparound (можно отнести к памяти)

Все остальное - проблемы вебмака и не распространяются на весь софт.

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