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

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

Ну как бы большинство до сих пор пишет с ограничением по ширине в 80/100 символов. И это вполне обосновано - узкий текст легче читается.

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

println кстати из паскаля.

Нет, это плод скрещивания паскалевского writeln и сишного printf.

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

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

У вас от этого болит? Приведите пример популярного языка без спец. символов.

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

в лучшем случае это будет низкоуровневый слой, но будет ли?

Теперь есть выбор, раньше его не было. Кто-то захочет запилить новый революционный движок и у него есть выбор: кресты или ржавый.

мозилле конец, других источников дохода у них нет

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

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

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

и прочее

Например?

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

И как тогда выглядит захват вне метода?

Это что?

let add_one = |x| x + 1;

Полагаю, что так:

Func<int, int> add_one = x => x+1;

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

Как поделка на коленке выглядит Microsoft Visual Studio.

Почему?

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

У вас от этого болит?

В очередной раз повторяю: мне это затрудняет чтение Rust-овского кода.

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

Не нужно подменять понятия: в Rust-е плотность спец. символов слишком большая. Есть языки, где она намного меньше. Например, C#.

И да, меня мало волнует, что C# — это язык с GC.

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

Хочешь сказать, что хром добавляет в DOM API отсебятину?

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

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

Мне интересно другое: в чем Rust-оманы пытаются меня убедить?

Моё мнение было основано на неверном представление о том, что Вам не понятно значение синтаксиса.

у Rust-а корявый и придумывали его те, кто хочет экономить на спичках и писать:

Ну покажите уж эталонный синтаксис? Назовите тот волшебный язык =) Нет его? Как так?

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

На работе мне приходиться частенько писать на делфи, где синтаксического сахара просто море, там и ваши public и function\procedure, но удобства или читаемости кода это не добавляет. По этому мне приятнее когда можно «экономить на спичках».

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

В сравнении с C++, никаких странных сокращений там нет.

А какие в С++ странные сокращения?

Если что меня вполне устраивают штуки типа fn в расте, но местами получается забавно. В макросах вон есть path или block, но ty.

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

Нет его? Как так?

Кто сказал, что его нет. Вот у Eiffel-я очень продуманный синтаксис, например. Код на C# и на Kotlin читается хорошо. Первые версии D были вполне себе хорошим исправлением наследия C и C++.

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

Нет его? Как так?

Ну или вот еще забавное вспомнилось. Где-то в районе 2009-2010-х годов, рядышком с анонсом Go, появилась информация о разработке языка Zimbu. Его делает основной разработчик Vim-а.

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

http://www.zimbu.org/Home/highlights — тут можно примеры посмотреть.

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

Кто сказал, что его нет. Вот у Eiffel-я очень продуманный синтаксис, например.

Мужик ты издеваешься????

note
   description: "Программа Здравствуй,мир!" 
   author: "Elizabeth W. Brown"
class 
  HELLO 
create 
  make
feature
  make
    -- Напечатать простое сообщение.
    do      
      print ("Hello World%N")
    end
end

Код на C# и на Kotlin читается хорошо

Большие классы на C# вызывают жгучую анальную боль, про Kotlin и D просто не знаю.

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

Мужик ты издеваешься????

Я, вообще-то, говорил про «продуманный синтаксис». Что в синтаксисе Eiffel-я вам кажется непродуманным?

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

Что в синтаксисе Eiffel-я вам кажется непродуманным?

ну он выглядит как говно, например.

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

Теперь есть выбор, раньше его не было. Кто-то захочет запилить новый революционный движок и у него есть выбор: кресты или ржавый.

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

Бекенды на го пишут полторы калеки

а вы совсем темный ;)

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

Отсутствие читабельности напрочь

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

Rust-оманы такие Rust-оманы :)

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

eao197 В общем, я понял Вашу позицию, но обед и работа требуют моего присутствия =)

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

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

Как контр-аргумент Eiffel выглядит не убедительно (= Вот и всё

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

Теперь есть выбор, раньше его не было

это к слову, например есть Qt, если кто то будет создавать фреймворк уровня Qt у него есть выбор - плюсы или раст, но кто в здравом уме будет на расте писать 10 лет фреймворк уровня Qt? в расте пока отделываются кривыми биндингами к существующим фреймворкам на c/c++

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

Мне не интересно ваше мнение.

А это тогда как понимать?

И этот вариант, по вашему, намного лучше?
Приведите пример популярного языка без спец. символов.

Мое мнение вам настолько не интересно, что вы не перестаете задавать мне вопросы.

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

К счастью, этим множество языков программирования не исчерпывается. Лямбды в Scala, насколько я помню, появились гораздо раньше начала работ над Rust-ом.

Так я и написал: не брать всякую экзотику. Походить имеет смысл только на язык, который хотя бы 30% периодически использует.

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

Вы, вероятно, не в курсе синтаксиса auto f() -> R.

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

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

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

какой смысл создание такого движка?

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

кто будет это вливать в движок на расте?

Да кто угодно, тот же автор майнкрафта проснется от летаргического сна и подумает куда пристроить свой миллиард.

и зачем

Любопытство и жажда славы, такова природа западного человека.

foror ★★★★★
()

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

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

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

Мыслишь слишком прямолинейно. Может статься так, что GUI для ржавого построят вокруг движка Servo, повыкидывав из него лишнее. И не нужно заливать мне про тормоза и пожирание ресурсов, ибо я тебе тут же кину ссылку на подобный проект для крестов, который жрёт 10Мб оперативки и работает не хуже нативного.

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

Так я и написал: не брать всякую экзотику.

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

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

Опять же, в отношении Rust-а у вас другая логика.

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

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

template<class T, class U>
? add(T a, U b) { return a+b; }
Поэтому и появился другой синтаксис. А лямбды уже использовали ту же нотацию.

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

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

Какой вы умный! Может объясните, почему разработчики Rust-а так не сделали?

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

С# 3.0 — это 2007-ой год. Ни C++11, ни Rust еще нет на горизонте.

В плюсах о планах на лямбды я где-то в начале 2000х читал, так что, скорее всего, текущий синтаксис году к 2005му более-менее устаканился.

Короче, если бы лямбды были в одном языке или в нескольких, но везде одинаковы и эти языки использовали бы регулярно 20%+ программистов на плюсах на момент начала работы над лямбдами в плюсах и этот синтаксис не выглядел бы совсем уж инопланетным, тогда имело бы смысл подумать о следовании общей традиции.

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

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

PNaCl

Плохой пример. Во-первых он deprecated. Во-вторых, был создан т.к. не было альтернативы древнему Netscape API. В-третьих, не является Web API

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

В плюсах о планах на лямбды я где-то в начале 2000х читал, так что, скорее всего, текущий синтаксис году к 2005му более-менее устаканился.

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

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

Он говорит, что оно внутри на крестах, так что как бы не считается.

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

Во-первых он deprecated

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

В-третьих, не является Web API

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

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

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

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

Если есть время - почему нет? Вроде как с 1 версии особо ничего не ломают. Нет. LLVM под капотом.

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

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

Есть языки, где в одной строке обычно говорится гораздо больше. Это APL и его потомки J и K. Вот в них уж точно нельзя программу бегло читать. Приходится каждую строку внимательно разглядывать, воспринимая скорее как математическую формулу. Но зато вся программа часто состоит всего из нескольких таких строк.

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