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)

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

фатальный недостаток в некоторых фичах других яп

Я тут шутку придумал про ООП: кошечка говорит мяу-мяу, собачка говорит гав-гав, и они являются объектами классов-наследников класса Животное. Поэтому, чтобы их покормить к ним нужно гвоздями прибить унаследованную миску с полиморфным кормом.

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

у ошибок часто бывает иерархия

Это не нужно.

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

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

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

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

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

Да ладно? И чем же «растовая лапша» хуже «try/catch лапши»? Я бы ещё понял, если бы тебе не нравилась необходимость разные Result к одному сводить.

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

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

Обычно «заменяторы» как раз и хотят отобрать у таких как я «старый добрый С»

Так они «не со зла», просто не хотят сами на С писать, вот и жалуются.

то какой смысл писать это на ЛОРе?

Популяризация - новым языкам она нужна. Да и о чём ещё писать? Я вон о расте именно из такой писанины и узнал. Проникся далеко не сразу, кстати.

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

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

И что? Мы же о «представить» говорим.

Unstable

Опять же, и что? Если так надо - можно уже использовать. Иначе просто подождём следующего релиза и будет «stable».

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

Проблема в уродливых макросах

Не понимаю. Ты говорил, что в расте не нужен «синтаксический мусор» в виде try/catch. Я говорю, что вместо него имеется свой мусор.

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

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

Прежде чем что-то вводить, как следует проработать.

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

До 2.0 как минимум. Если хотят быть продакшеном то в 2.0 депрекейтнуть а в 3.0 выкинуть.

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

Если ввели в 1.0 то глотать. Сами виноваты.

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

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

но не менее чем через N месяцев после отметки. Вроде как это и есть метод раста.

А вот не менее через N месяцев - это вообще не к чему.

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

Или я тебя не понял

Может, он говорит о том, что введение новых ошибок в Rust ломает внешний интерфейс крейта, в отличие от Си++/Java/whatever?

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

Если хотят быть продакшеном то в 2.0 депрекейтнуть а в 3.0 выкинуть.

Да ладно, если выкинут в 2.0 тоже нормально будет.

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

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

Может, он говорит о том, что введение новых ошибок в Rust ломает внешний интерфейс крейта, в отличие от Си++/Java/whatever?

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

Ну и думаю, что мы солидарны в том, что новые исключения «ломающие интерфейс» - это наоборот хорошо.

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

Может, он говорит о том, что введение новых ошибок в Rust ломает внешний интерфейс крейта, в отличие от Си++/Java/whatever?

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

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

Дык, он ведь хочет «декларировать исключения, которые обязательно обработать»

Объявить, что пользователь должен обработать MyException, а потом всю жизнь добавлять производные от MyException классы.

Ну и думаю, что мы солидарны в том, что новые исключения «ломающие интерфейс» - это наоборот хорошо.

Ну, в случае Си++ есть возможность добавить исключение, не сломав ABI. Хотя так ли это полезно...

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

Ломать интерфейс для исправления ошибки - нехорошо.

А добавление новой ошибки ты не считаешь сломом интерфейса? Не ABI, а именно интерфейса?

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

Объявить, что пользователь должен обработать MyException, а потом всю жизнь добавлять производные от MyException классы.

Толку от этого даже меньше чем от noexcept.

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

А добавление новой ошибки ты не считаешь сломом интерфейса? Не ABI, а именно интерфейса?

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

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

А добавление новой ошибки ты не считаешь сломом интерфейса? Не ABI, а именно интерфейса?

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

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

С точки зрения кровавого тырпрайса:

быдлокодеры не могут в низкоуровневое системное программирование, а писать дрова то надо, давайте сделаем макакам аппарат Елизарова!

С точки зрения быдлокодеров:

Си - устаревшее гуано, нинужно, закопать, ко-ко-кукареку!

С точки зрения тех, кто может в низкоуровневое системное програмирование:

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

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

А тем временем нормальные люди запилили ОС (на самом деле нет) на nim: https://github.com/dom96/nimkernel

ИЧСХ, у nim есть опция сборки в Си, что дает возможность присобачить его к любому компилятору под любую архитектуру, в отличии от этого вашего хруста.

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

С точки зрения кровавого тырпрайса:

Язык «ещё не готов»: библиотек мало, специалистов мало и т.д.

С точки зрения быдлокодеров:

Дурацкий язык, не позволяет непринуждённо стрелять в ногу, никуда не годиться.

Пофиксил, не благодари.

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

ИЧСХ, у nim есть опция сборки в Си, что дает возможность присобачить его к любому компилятору под любую архитектуру, в отличии от этого вашего хруста.

Недавно в компиляторе был реализован дополнительный уровень MIR, который облегчит переход на аналог LLVM в случае необходимости. Можно даже его интерпретатор сделать, либо конвертацию в C - но зачем?

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

ИЧСХ, у nim есть опция сборки в Си, что дает возможность присобачить его к любому компилятору под любую архитектуру, в отличии от этого вашего хруста.

И как, много архитектур Nim уже поддерживает? Официально, конечно.

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

Язык «ещё не готов»: библиотек мало, специалистов мало и т.д.

Никак не противоречит идее с аппаратом Елизарова.

Дурацкий язык, не позволяет непринуждённо стрелять в ногу, никуда не годиться.

Не видел ни одного быдлокодера, который бы такое говорил, или писал. Типичный разговор с макаками выглядит так:

Ну и что за говно ты тут написал?

У миня фсё работаит!

А это что за unhandled exception?

Пофиксил, не благодари!

А тут, что за сегфолт?!!

А с чего ты взял, что пользователь введет такое начение в это поле ввода?

Что касается Rust, то он таки позволяет отсрелить себе ногу, и об этом говорилось по меньшей мере в трех крайних растотредах, после чего включалось ВРЕТИИИ и прочая сверхманевренность.

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

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

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

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

И как, много архитектур Nim уже поддерживает? Официально, конечно.

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

сверхманевренность.png

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

Я не говорил про официальную(тм) поддержку изначально, но если тебе так угодно, то:

https://github.com/nim-lang/csources/blob/b39a1df5d226ab523ee9eadb5e77444af86...

Там есть:

STRING_LITERAL(TMP63, "i386", 4);
STRING_LITERAL(TMP64, "m68k", 4);
STRING_LITERAL(TMP65, "alpha", 5);
STRING_LITERAL(TMP66, "powerpc", 7);
STRING_LITERAL(TMP67, "powerpc64", 9);
STRING_LITERAL(TMP68, "powerpc64el", 11);
STRING_LITERAL(TMP69, "sparc", 5);
STRING_LITERAL(TMP70, "vm", 2);
STRING_LITERAL(TMP71, "ia64", 4);
STRING_LITERAL(TMP72, "amd64", 5);
STRING_LITERAL(TMP73, "mips", 4);
STRING_LITERAL(TMP74, "mipsel", 6);
STRING_LITERAL(TMP75, "arm", 3);
STRING_LITERAL(TMP76, "arm64", 5);
STRING_LITERAL(TMP77, "js", 2);
STRING_LITERAL(TMP78, "nimrodvm", 8);
STRING_LITERAL(TMP79, "avr", 3);
STRING_LITERAL(TMP80, "msp430", 6);

Как минимум, они работают над этим.

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

Я не говорил про официальную(тм) поддержку изначально

А я с самого начал спрашивал именно про это.

но если тебе так угодно

Мне угодно заявление core team, а не кусок препроцессированного исходника.

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

Прежде чем что-то вводить, как следует проработать.

Ага, выпустить идеальную версию 1.0 и обновлений не выпускать, так как улучшать нечего.

До 2.0 как минимум.

Так и так вроде ж. В 1.10 депрекейтнут, в 2.0 выкинут.

Если хотят быть продакшеном то в 2.0 депрекейтнуть а в 3.0 выкинуть.

Смысл? У данного решении я вижу 2 недостатка: отсутствие флажка депрекейтед на интервале 1.10-2.0 приведёт к увеличению количества кода, использующего этот устаревший метод, а необходимость ждать 2 мажорных релиза до удаления откладывает плюшки от избавления от кривого API на несколько лет. Достоинств же вообще нет. Собственно, ради чего ждать мажорного релиза перед депрекейшеном? Чтоб у кого-то ворнинги при компиляции не выскочили?

А вот не менее через N месяцев - это вообще не к чему.

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

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

Ты понимаешь, что такое Си?

Это переносимый язык программирования.

Ключевое слово — ПЕРЕНОСИМЫЙ!

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

Соответственно возможность использовать некий ЯП, который можно транслировать в Си, на некой платформе определяется наличием достаточных ресурсов на этой самой платформе.

А вот, кстати, проект для не 32-разрядной архитектуры: https://github.com/lonetech/nim-msp430

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

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

Лет конечно же 14, а IQ=88, естественно!

Когда там Rust на msp430 планируют завести?

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

Все конечно замечательно, но синтаксис как в питоне это жесть. Я знаю почему он такой в питоне, но зачем его сюда притащили не могу понять. Хотя, кому как нравится. *пошел писать свой кодогенератор...*

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

Это не просто кусок Видного файла, это кусок выхлопа компилятора nim, которому скормили исходники его же самого, и сказали сделать Си. В оригинале код выглядит так: https://github.com/nim-lang/Nim/blob/devel/compiler/platform.nim

Это можно считать официальным заявлением?

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

Синтаксис Rust, это жесть. А тут противно, конечно, но пользоваться можно.

Ну и интерпретатор Lisp на nim содержит раза в 2 меньше кода, чем он же на Rust.

Выразительность, понимаешь!

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

Ну так Nim использует сборщик мусора. Естественно кода меньше будет.

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

Наш 14-летний друг заявил, что Nim более переносимый, но не предъявил списка поддерживаемых архиьектур. У Rust он по крайней мере есть.

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

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

Если это отличие выливается в необходимость выстраивать цепочку из try! вместо обычной цепочки вызовов функций, то это несколько сомнительное преимущество.

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

Так что посмотрим, что эти фанаты смогут сделать. Может годика через два-три это окажется вполне себе годным инструментом.

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

Везде где есть cc, можно завести и nim.

Принципиальная возможность меня не интересует. Я спрашивал о... выше написано, о чем.

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

синтаксис как в питоне это жесть

А что с ним не так?

Я знаю почему он такой в питоне

Ну отлично. Просвети и нас, если не трудно.

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

у nim есть опция сборки в Си

Генерация C кода, и его работа на всех устройствах - это разные вещи.

Можно даже JS сконвертировать в C, но на микроконтроллере он от этого не заработает.

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

сверхманевренность

Если мне не изменяет память, она включалась у макак, которые по-своему понимают memory safety.

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