LINUX.ORG.RU

Rust 1.18

 


1

10

Команда Rust анонсирует релиз 1.18.

Обновление предыдущей версии легко:

$ rustup update stable

Сам rustup можно установить здесь.

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

Одно из главных изменений - новая версия «The Rust Programming Language», официального учебника по Rust. Он пишется открыто на Github, и имеет более ста авторов. В этом релизе включен черновик второй версии книги, имеющий 19 из 20 глав; двадцатая глава будет готова к релизу 1.19. Купить бумажную версию можно через No Starch Press. Новая версия книги полностью переписана и учитывает последние два года нашего опыта обучения Rust. Вы найдете новые объяснения основных принципов Rust, новые проекты и прочее.

В самом языке улучшено ключевое слово pub. По умолчанию, в Rust объекты приватны; можно использовать pub чтобы сделать их публичными. В Rust 1.18, pub имеет новый вариант:

pub(crate) bar;

Слово в скобках - ограничение, контролирующее степень публичности объекта. Если указанно pub(crate), то bar будет публичным для всего крейта (пакета), но не вне него. Это позволяет декларировать интерфейсы, «внутренне публичные» для пакета, но не доступные для внешних пользователей.

Также можно указать путь, например:

pub(in a::b::c) foo;

Это значит «доступно в иерархии a::b::c, но не в прочих местах».

Для пользователей Windows Rust 1.18 имеет новый атрибут, #![windows_subsystem]. Он работает так:

#![windows_subsystem(console)]
#![windows_subsystem(windows)]

Он контролирует флаг /SUBSYSTEM в компоновщике. На текущий момент доступны только console и windows. Если вы разрабатываете графическое приложение, и не указываете windows, в момент пуска программы всплывет окно консоли. С атрибутом windows этого не произойдет.

Далее, в Rust кортежи, варианты перечисляемых типов и структуры (без атрибута #[repr]) всегда имели неопределенное расположение в памяти. Мы включили автоматическое упорядочивание, которое может привести к уменьшению потребления памяти путем уменьшения необходимого выравнивания. Например:

struct Suboptimal(u8, u16, u8);

В прежних версиях Rust на платформе x86_64 эта структура имела бы размер в шесть байтов. Но согласно исходному коду, ей достаточно должно быть четырех. Остальные два байта - результат выравнивания. Поскольку мы имеем u16, он требует двух байтов. Но в данном случае, он был смещен на один байт из-за предыдущего u8. Для последнего же u8 требуется еще один байт выравнивая. В итоге, мы имеем 1 + 1 (пусто) + 2 + 1 + 1 (пусто) = 6 байтов.

Но что если структура выглядит так?

struct Optimal(u8, u8, u16);

Эта структура оптимально выравнена; u16 находится на рубеже двух байтов, как и остальная структура. Выравнивание не требуется. Это дает нам 1 + 1 + 2 = 4 байта.

При дизайне Rust мы оставили физическое расположение данных в памяти неопределенным как-раз по этой причине; любой safe-код (не следующий по «сырым» указателям) не будет затронут подобной оптимизацией. Благодаря этому, мы можем научить компилятор оптимизировать Suboptimal в Optimal автоматически. В Rust 1.18 обе структуры занимают в памяти размер в четыре байта.

Мы долго планировали это изменение; оно было и ранее в нестабильной версии Rust, но некоторые программисты писали unsafe-код, который предполагал определенное расположение данных в памяти. Если вам необходима гарантия, что физическое расположение в памяти в точности совпадает с расположением вариантов в исходном коде (например, при обращению к оболочкам Cи-кода), пометьте вашу структуру с атрибутом #[repr(C)].

Напоследок, улучшено время компиляции; например, компиляция самого rustc теперь на 15%-20% быстрее.

Стабилизированы следующие библиотеки:

  • Child::try_wait, неблокирующая форма Child::wait.
  • HashMap::retain и HashSet::retain - версия существующего retain от Vec<T> теперь и у этих двух структур.
  • PeekMut::pop позволяет взять ранее прочитанный верхний элемент от BinaryHeap<T> без необходимости повторно упорядочивать кучу.
  • TcpStream::peek, UdpSocket::peek, UdpSocket::peek_from позволяют прочесть крайний элемент у потока или сокета.

Новый функционал Cargo

Cargo добавил поддержку системы управления версиями Pijul, который написан на Rust:

cargo new my-awesome-project --vcs=pijul

У Cargo несколько новых флагов, дополняющих --all: --bins, --examples, --tests и --benches позволяют собрать все программы указанных типов.

И наконец, Cargo теперь поддерживает Haiku и Android.

Подробнее об изменениях написано здесь.

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



Проверено: Shaman007 ()
Последнее исправление: cetjs2 (всего исправлений: 7)

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

Что-то в отношении Rust-а у вас другая логика.

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

Посконный подход не работал с шаблонными функциями вида

Насколько я помню, это с помощью decltype решалось, не?

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

Просто за тем, чтоб обратить ваше внимание, что никаких общих лямбд не существует. Даже языки, мимикрирующие под C++, реализовали лямбды вразнобой. Соответственно к Расту, авторы которого сознательно решили не тащить с собой синтаксис C претензии на не похожий синтаксис вообще неприменимы.

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

Если бы не было конкуренции, сейчас бы юзал его во все поля

Какой конкурент затмил PNaCL?

Вот именно! Вот именно поэтому нельзя допускать, чтобы хромой остался один

То-есть предлагаешь вернуть Netscape API?

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

Вам же хотелось лямбды «как везде»? Так вот, этого «везде» не было. Ферштейн?

Это вам так кажется. Синтаксис лямбд в C# оказался очень похож на синтаксис лямб в Scala. Потом почти такой же оказался в Java.

В функциональной экзотике, вроде Haskell-я, был свой синтаксис. Но Rust и на него не похож.

Так что Rust-оделы отчебучили очередную отсебятину, как с fn, mut, i32 и пр.

Насколько я помню, это с помощью decltype решалось, не?

Вы неправильно помните. decltype появился в C++11. Вместе с новым синтаксисом для функций и лямбдами.

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

Таков принцип ИТ - в постоянном развитии. Да, сейчас вроде всё устаканилось, все радуются заскриптованым полигональным движкам. Но кого-то это может не устроить, кто-то захочет воксельный движок на нейронных сетках. Или что-то в подобном духе.

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

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

У меня нет причин верить вам на слово. В 2003-ом году был принят корректирующий стандарт C++03, в котором никаких лямбд не было.

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

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

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

Ну так дайте ссылку на пропозал для добавления лямб в C++ от начала 2000-х, делов-то.

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

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

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

Почему на любителя?

Потому что:

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

Вам такое нравится, мне нет. Поэтому и на любителя.

Судя по восстребованности Haskell-я любителей не так уж и много.

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

кто в здравом уме будет на расте писать 10 лет фреймворк уровня Qt?

Кто в здравом уме будет делать: «full-featured Operating System, providing packages (memory allocator, file system, display manager, core utilities, etc.) that together make up a functional and convenient operating system» Но делают же, вкладывают в это деньги они же могут предложить фреймворк для разработки GUI.

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

Может и будет в разы быстрее в многопоточном режиме для практически написанных программ. В Расте, например, берешь библиотеку Rayon, заменяешь .iter() на .par_iter(), и пишешь цикл как обычно. Библиотека сама разбивает цикл на части, оптимизируя под количество доступных ядер и размера задачи. А компилятор гарантирует при этом отсутсвие гонок данных, UB, и прочих «прелестей» мультипоточного программирования.

Теоретически все это можно достичь и в C или C++, но безопасное многопоточное программирование там такое сложное, что и гуру ногу сломит.

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

Зачем две точки в параметрах? Вот какую практическую цель они несут? Почему другие языки без них обходятся?

Да уж, видно как ты на новые языки смотришь. Swift, Kotlin, Scala, Rust и т.д.

Зачем оно надо - задача для самостоятельного изучения. Массовое помешательство, не иначе.

Остальные претензии на уровне.

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

Синтаксис у Zimbu представляет из себя вообще гремучую смесь. Но въезжаешь в него очень быстро.
http://www.zimbu.org/Home/highlights — тут можно примеры посмотреть.

Moolenar - известный наркоман. ОДНА закрывающая «}» для блока. Одна, Карл! Просто потому, что некоторые не могут выбрать где её ставить - на той же строке или на следующей.

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

Это вам так кажется. Синтаксис лямбд в C# оказался очень похож на синтаксис лямб в Scala. Потом почти такой же оказался в Java

Ну это, положим, неправда: в Java сделали совершенно безумную замену => на ->. Смысла никакого, зато не как у всех.

Так что Rust-оделы отчебучили очередную отсебятину, как с fn, mut, i32 и пр

Т. е. можно всем, кроме раста?

Вы неправильно помните. decltype появился в C++11. Вместе с новым синтаксисом для функций и лямбдами.

Обсуждения были гораздо раньше. В принципе могли обойтись decltype. Если лень писать выражение, могли бы сделать decltype f(A a, B b) {return a+b;}, или decltype(auto) f(A a, B b) {return a+b;}

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

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

int, char, struct, decltype.

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

Ну и с утверждением «в сравнении с C++, никаких странных сокращений в расте нет» я не согласен. Сокращения имеются в обоих языках, странность их вопрос субъективный.

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

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

На счет гарантий со стороны компилятора четверть соседней темы про Rust была этому посвящена: Продемонстрирована возможность разработки частей Linux на Rust (комментарий)

Теоретически все это можно достичь и в C или C++, но безопасное многопоточное программирование там такое сложное, что и гуру ногу сломит.

Поэтому в C/C++ уже давно есть OpenMP, Intel Threading Building Blocks, HPX и пр. Даже в C++17 будут готовые средства «из коробки».

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

Ну это, положим, неправда: в Java сделали совершенно безумную замену => на ->.

Нда, различие между => и -> это вовсе не «почти такой же». Растоманы, бл*дь.

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

С++11 уже формировался на основе опубликованных в Интернете пропозалов. Если настаиваете на своей точке зрения, то покажите соответствующие пропозалы.

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

Moolenar - известный наркоман.

Да, синтаксис тот еще. Но читается легко после беглого знакомства с языком.

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

Ну так дайте ссылку на пропозал для добавления лямб в C++ от начала 2000-х, делов-то.

Что ещё вам дать? Я ориентируюсь по своей памяти, на плюсы я забил в 2005м, статьи на тему «куда дальше плюсам податься» читал до этого.

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

Соседняя тема сводится к аргументу, «выполнить команду через sudo, а потом жаловаться, что Линукс не защитил от опасной команды». unsafe тот же sudo. Не уверен - не используй.

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

Я ориентируюсь по своей памяти

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

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

Он уже встроен во все компиялторы и дайт по рукам?

Тимлид встроит и выдачу автолюлей настроит

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

Не уверен - не используй.

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

И об этом хорошо бы помнить. Поскольку адепты-евангелисты Rust-а много говорят о гарантиях, подразумевая при этом «100% гарантию дает только страховой полис».

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

странность их вопрос субъективный

Я об этом же.

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

Нда, различие между => и -> это вовсе не «почти такой же». Растоманы, бл*дь.

Нет. Это «хоть как, лишь бы по-другому». Чтоб проклятые шарписты и скалисты на каждой лямбде запинались.

С++11 уже формировался на основе опубликованных в Интернете пропозалов. Если настаиваете на своей точке зрения, то покажите соответствующие пропозалы.

Ваш идиотизм меня достал. Пропозал, видимо, Вася за день до публикации на коленке сварганил. Ни с кем не обсуждая, без сложившегося консенсуса на тему «неплохо бы этакое иметь», верно?

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

кто делает то? студенты?

Читал, что какая-то контора, сейчас присмотрелся и правда один человек в основном пилит (не студент). Но человек шарит в теме.

где ось планируется использоваться?

На десктопе

кастомеры есть?

Есть, как минимум у людей есть интерес что может выйти на ржавом в плане ОСи.

ты уже пишешь с этой оси?

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

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

Пропозал, видимо, Вася за день до публикации на коленке сварганил.

Ну так покажите этот пропозал, делов-то.

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

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

В Линуксе, как только начинается что-то нетривиальное с пространством ядра (вроде патча ядра), админу приходится уходить в sudo. И гарантии от системы защиты Линукса при этом становятся равны радиусу кривизны рук админа.

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

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

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

Советую почитать историю Linux.

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

Как по мне так правильнее подход из фортрана где write может делать и форматный и неформатированный вывод в любой юнит. А что подставлять вместо юнита это уже забота программиста. При желании оператор позволяет в строку (char) печатать с заданным форматом.

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

Ну так покажите этот пропозал, делов-то.

Последняя попытка.

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

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

Когда на нём будет что-то номальное для гуйни.
т.е. нужен аналог qtgui.

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

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

У меня нет оснований доверять вашим словам о том, что это все оформилось в районе 2005 года. Запросто могло быть и в районе 2007, и в районе 2009.

eao197 ★★★★★
()
Ответ на: комментарий от AntonyRF
public function backup(&mutable self, path: &mutable String) -> Result<()> {
pub fn backup(&mut self, path: &mut String) -> Result<()> {

Очевидно, что второй вариант легче читается

Вовсе не очевидно. Мне, например, первый вариант прочитать легче, чем второй.

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

Смысл? Я с вами не первый раз общаюсь, верить вам на слово не вижу причин. Так что ваши слова о 2005-ом годе не заслуживают никакого доверия, если им не найдется документальное подтверждение.

Мне искать это подтверждение не нужно.

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

имеет ли смысл изучать сие?

Да, хотя бы просто почитать русскую доку для ознакомления с оф.сайта

Насколько стабилен синтаксис?

После 1.0 версии обещали не ломать совместимость

Нет ли извращений вроде питоновских обязательных отступов?

Обязательных отступов нет, но язык сам по себе не обычный. Например, ООП которое совсем не такое как в С++

Как с производительностью?

На 1-2% хуже чем в чистом Си

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

Меня напрягает другое - сигнатура &mut String а не mut &String, ведь индикатор среза относится к типу, а не к переменной. В версии без mut так и пишется слитно, &String.

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

Лихо вы сравнили. Часть выражения из Rust-а с полным выражением из C#. Адекватненько. LOR-овские Rust-оманы в своем стиле.

Хватит делить на ноль

Мне вот интересно, кто-нибудь и защищающих Rust-овый синтаксис сможет ответить на мои вопросы: Rust 1.18 (комментарий) ?

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

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

Добро пожаловать в реальную жизнь. Или ты думаешь, что компилятор (например) плюсов мало «магии» делает? Зачем по твоему нужны undefined/unspecified/implementation-defined behavior?

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

Ты совершенно прав. Мое высказывание было сарказмом на фразу предыдущего оратора.

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

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

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

имеет ли смысл изучать сие?

Зависит от задач, смотря что вы хотите на нем делать.
А если без конкретных задач и просто для себя — однозначно да.

Насколько стабилен синтаксис?

Обратно совместим, периодически добавляют новый сахар, но ничего не ломают с 1.0

Нет ли извращений вроде питоновских обязательных отступов?

Нет

Как с производительностью?

На уровне C и C++

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

Мне вот интересно, кто-нибудь и защищающих Rust-овый синтаксис сможет ответить на мои вопросы: Rust 1.18 (комментарий) ?

Тебе уже ответили, но поменять твоё мнение и субъективное восприятие ни кто не будет даже пытаться

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