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

А так я здесь, в отличии от вас, не страдаю.

А я страдаю, по-вашему? ;)

Как я сказал в другой теме, мне не нравится то, что происходит в мире C++. Единственная видимая альтернатива — это Rust. Поэтому, чем раньше Rust захватит изрядный кусок рынка (не важно, от C++ или от каких-то других языков), тем лучше для меня. Но, судя по адекватности Rust-оманов, этого ждать придется еще долго.

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

В случае необхоимости я могу привести к базовому классу?

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

MyTrooName ★★★★★
()

Эххъ. Особо умные программисты на Расте уже появляются. Сейчас на реддите встретил. Товарищу неудобно работать с RefCell, поэтому он трансмутирует ссылку на содержимое RefCell в &'static, и доволен тем как он упростил себе работу. То, что он создал UB, его похоже не волнует, пока программа работает.

А она будет работать только до тех пор пока LLVM не научат использовать все гарантии no-aliasing, которые должны давать ссылки Rust'а.

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

Эххъ. Особо умные программисты на Расте уже появляются. Сейчас на реддите встретил. Товарищу неудобно работать с RefCell, поэтому он трансмутирует ссылку на содержимое RefCell в &'static, и доволен тем как он упростил себе работу. То, что он создал UB, его похоже не волнует, пока программа работает.

главный признак того, что язык созрел. эх...

MyTrooName ★★★★★
()

Заинтриговали вы меня. Устанавливаю сейчас на второй компьютер. Первое впечатление, что все сделано очень добротно

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

Про bindgen слышу в первый раз. Что сильная вещь?!

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

https://github.com/pftbest/x11-rust-example/blob/master/examples/xshm.rs

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

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

Как я сказал в другой теме

Кажется в той теме я попкорн не ел.

Но, судя по адекватности Rust-оманов, этого ждать придется еще долго.

Простите, уточню. Вы говорите об адекватности местных или разработчиков? И если второе, вы жалуетесь на их неадекватность на ЛОРе? ;-)

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

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

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

Алан Кей говорит, что его представление об ООП идеал, его противники говорят, что нифига. Но ладно, пусть.
По мне так всё ООП это многословная ересь, тут я полностью согласен с Дейкстрой:
«I don’t think object-oriented programming is a structuring paradigm that meets my standards of elegance.» (c)

anonymous
()

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

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

Я тоже считаю, что без ООП можно жить. Особенно ООП выглядит как костыль когда разработка идёт под микроконтроллеры, но меня тут уверяли что без ООП ну ваааааапще ни как.

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

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

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

А при чем тут С++?
Во-первых, к С++ давно привыкли, множество его подводных камней изучено, известно как их обходить.
Во-вторых, если растоманы так батхёртят от С++, зачем же нужно было создавать свой клон С++ с блэкджеком и шлюхами владением и выводом типов?
В-третьих, С++ на самом деле в последние годы превращается в тыкву. Раст его в этом опередить хочет? Ему удалось.
Смешивать парадигмы до такой степени не самая хорошая идея, но если С++ пока спасает наработанный опыт, то расте этого опыта нет и не появится, он изначально тыквой родился.

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

костыль когда разработка идёт под микроконтроллеры


А как надо код структурировать, процедурно? Назад к Паскалю тогда. Как раз для микроконтроллеров вполне подходит.

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

И вообще отказаться от необходимости описывать отдельно trait, struct, impl. Если уже есть, то извиняюсь, не видел.

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

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

А как надо код структурировать, процедурно? Назад к Паскалю тогда. Как раз для микроконтроллеров вполне подходит.

Ещё один... Эх... Делай как тебе нравиться, ни кто не заставляет тебя и всех тут менять свои привычки. Просто у тебя тоже подгарит, когда я тебе скажу что ООП не даёт преимуществ в скорости разработки, но ты как и остальные подобные тебе будут мне с пеной у рта доказывать, что это не так, потому что не в состоянии понять что можно делать что-то по другому...

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

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

Это сравнение шаблонов плюсов с дженериками раста или со всеми возможностями последнего? Если второе, то спорно.

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

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

Просто у тебя тоже подгарит, когда я тебе скажу что ООП не даёт преимуществ в скорости разработки

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

eao197 ★★★★★
()

Пока лингвисты-теоретики в этой уютной теме обсуждают качество синтакса и определение ООП, в Расте открылся новый RFC по внедрению ко-рутин (на основе генераторов, вспоминаем питоновский yield) и сахара в форме async/await, как значительно более удобный метод чем ручное управление Future-ами.

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

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

а то что он автоматически такое сейчас не ловит - ну сорян, отпишы в багтреке

Так это сознательное решение было.

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

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

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

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

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

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

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

Ещё раз вопрос: rust это ооп или нет? Если да, то где наследование? Если нет, то и вопросов нет.

В расте есть только наследование трейтов (интерфейсов), но не данных.

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

Веб-фреймворк rocket-rs вытягивает проходимость 75.000 реквестов в секунду на одном шестиядерном Xeon-е, с лагом одного реквеста порядка 5 микросекунд. Разумеется, без БД и прочих усложнений, просто HTTP request/response.

Несколько других вариантов вроде hyper, аналогично (там еще старые цифры с 2016, с тех пор библиотеки чуть поулучшились).

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

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

Сокращение не должно быть в ущерб восприятию

В примере выше используются кортежи. На плюсах вместо c.1 будет std::get<1>(c). Никто так писать не заставляет, но и не препятствует, ага.

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

Веб-фреймворк rocket-rs вытягивает проходимость 75.000 реквестов в секунду на одном шестиядерном Xeon-е

Подозреваю, что Go-шный fasthttp на таком же железе будет показывать в разы большую пропускную способность.

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

A какой нибудь PHP разрывает их обоих. :-)

Надо учесть хотя бы, что Go 1.0 вышел в 2012, а Rust 1.0 в 2015, разница более чем в два раза от сегодняшнего дня.

Ну и кстати я, между прочим, ничего не имею против Go. Язык и язык, простой довольно, особенно как этап после Питона или Руби, производительность приличная. Но есть сферы, где этого недостаточно.

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

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

Mожно сделать дополнительную обёртку, но есть такая проблема, да.

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

A какой нибудь PHP разрывает их обоих. :-)

у пхп другая ниша - визитки и интернет магазины, поэтому там где берут Go или Java, пхп не рассматривают

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

Но есть сферы, где этого недостаточно.

Если даже гуглу достаточно, когда у них самые большие данные, то где вам может быть недостаточно?

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

Не путаем базовый веб-сервер (сравнимый с Nginx, и то не полностью) с динамичным веб-фреймворком (сравнимый с Node итп). Сложность обработки запроса, даже простейшего, совсем другая.

Если сравнивать fasthttp, то вот его сравнение с теми же Futures из Rust (теми самыми, над которыми сейчас строится абстракция ко-рутин). Rust быстрее где-то на 25% - два миллиона запросов в секунду против полутора.

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

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

Rust внезапно хочет стать Go? не поздно?

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

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

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

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

Если сравнивать fasthttp, то вот его сравнение с теми же Futures из Rust (теми самыми, над которыми сейчас строится абстракция ко-рутин). Rust быстрее где-то на 25% - два миллиона запросов в секунду против полутора.

Ну вот про такое сравнение я вас и спрашивал. Спасибо за ссылку.

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

У них и компьютерные сети самые большие, и архитектура динамично расширяется, и большинство задержек в сетевом IO. Там Go хорошо зайдет, не спорю. К сожалению, большое количество приложений не имеют таких возможностей.

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

Но, судя по адекватности некоторых лоровских Rust-оманов, этого ждать придется еще долго.

Пофиксил.

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

Если сравнивать fasthttp, то вот его сравнение с теми же Futures из Rust (теми самыми, над которыми сейчас строится абстракция ко-рутин). Rust быстрее где-то на 25% - два миллиона запросов в секунду против полутора.

учитывая что бенчмарки проводил человек заинтересованный в Rust и Go всеголишь на 25% медленее я бы задумался о том какие бенчмарки тебе бы выдал гофер.

и да, если мы возьмем за правду, что Go действительно медленее в реал ворлд серверсайде на таких задачах на 25%, Rust внезапно с таким мелким профитом и кучей других недостатков (сложность обучения и входа, медленее писать код) никому не нужен

umren ★★★★★
()
Последнее исправление: umren (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.