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)

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

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

Как следствие в данном случае совершенно не нужны все эти дополнительные классы.

Ты таки не ответил на вопрос. У кого более косное мышление: у того, кто просто пишет код, или у того, кто сразу начинает думать, в какой шаблон засунуть полученное недо-ТЗ?

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

В точку, хотел его привести в пример, но перепутал эти фреймворки )

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

Ты таки не ответил на вопрос. У кого более косное мышление: у того, кто просто пишет код, или у того, кто сразу начинает думать, в какой шаблон засунуть полученное недо-ТЗ?

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

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

а почему в фаерфоксе не виснет?

В ФФ уже интегрированы наработки на расте с тестового полигона Servo, проекты называются Quantum и Stylo.
Мир не рухнул?

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

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

Вы не знаете Rust и это логично что вам тяжело читать на нем чужой код. У меня проблем при контрибьютинге в тот же rustc не возникало с чтением кода, хотя код там так себе местами по гайдлайнам раста.

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

Ты хоть раз рылся в коде llvm?

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

pftBest ★★★★
()

Кстати, собственно кто нибудь пробовал пользоваться Pijul? Уже убийца Гита или пока еще нет?

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

Вы не знаете Rust и это логично что вам тяжело читать на нем чужой код.

Ну вот код на Ceylon-е или на Kotlin-е воспринимается нормально. А код на Rust-е — нет. И здесь дело не столько в уникальных особенностях Rust-а (вроде borrow checker-а), а в его насыщенности. Ну, например:

struct Point {x: f64, y: f64}
fn get_x<'r>(p: &'r Point) -> &'r f64 { &p.x }
Здесь в объявлении get_x очень много _значимых_ одно-двух-трех буквенных сочетаний. fn — важная вещь, ' - важная вещь, r после апострофа — опять важная вещь, p — как название параметра, тоже важно, как и символ & после двоеточия, как и 'r после &. Не говоря уже про сочетание &'r f64.

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

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

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

Вообще-то auto досталось в наследство от C.

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

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

Скорее вся индустрия на объектных сях, шарпе, джаве и флеше.

unity 3d - ядро на плюсах, unreal engine - плюсы, cryengine - плюсы, lumberyard - плюсы, консоли (хбокс, свитч, пс4) - плюсы, все движки на андроиде под низом на плюсах, иос (SpriteKit, SceneKit) - на плюсах, ubisoft - anvil - плюсы, EA Frostbyte - плюсы. Мне продолжать? где там раст? его нет

То, что раз в год выпустят несколько ААА на плюсах, не делают всю индустрию на плюсах

а ты покопайся, даже все популярные решения на которых сейчас индюшатина сидит почти все ядра в движках там на плюсах (не все), а все что за пределами индюшатины кроме как на плюсах и не делается, а твои игры на js тоже на плюсах, и во флеше так же ядро и графоний на плюсах если что

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

С той же семантикой, что и в современном C++? Да что вы говорите.

В C++ не придумывали новое ключевое слово, в отличии от Rust-а. Что до «новой семантики» до в Design and Evolution of C++ Страуструп писал, что идея использовать auto для автоматического вывода типа переменной была еще в 80-х, но он не стал так делать ради сохранения совместимости с C. Реализовать эту идею смогли только в C++11.

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

Atom, Eclipse Che, Visual Studio, Google Docs, PgAdmin, Thunderbird и еще куча софта, лень вспоминать и перечислять.

Atom, Eclipse Che, Visual Studio - это текстовые редакторы, где там крутые возможности десктопа я не знаю, тормозят все три как бешеные

Google Docs

норм

PgAdmin, Thunderbird и еще куча софта, лень вспоминать и перечислять.

какое то ненужно

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

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

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

про это 3 года кудахтают уже, что вот «осенью» будет файрфокс на расте, и так каждый год повторяется, файрфокс скоро вообще умрет уже, за ним может и ржавый твой, смотри внимательно на график

Массово может и нет

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

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

Это избыточная запись, можно просто написать так:

struct Point {
    x: f64, 
    y: f64
}

fn get_x(p: &Point) -> &f64 { 
   &p.x 
}

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

Я согласен что код читать сложнее чем на, например, Go, где синтаксис очень простой, но там и прочитать надо будет намного больше текста.

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

В C++ не придумывали новое ключевое слово, в отличии от Rust-а.

В Rust придумали целый язык, все ключевые слова. В чем-то вы тут правы :)

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

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

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

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

Чем fn хуже def, например? Указание времен жизни требуется редко, а использовать однобуквенные названия никто не заставляет. Неужели так сложно понять, что происходит тут: fn first_of_any(list : &'persistent [i32], values_to_find : &'temp [i32]) -> &'persistent i32 {...

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

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

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

Нужны ещё <'persistent, 'temp>. Я бы сделал такой пример:

fn search<'a, 'b>(haystack: &'a str, needle: &'b str) -> &'a str {...}
anonymous
()
Ответ на: комментарий от mersinvald

Если это пример реального кода с GH, дайте ссылку, я товарищу PR зашлю.

Это пример из документации: https://doc.rust-lang.org/0.12.0/guide-lifetimes.html

Я согласен что код читать сложнее чем на, например, Go, где синтаксис очень простой

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

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

результаты в целом более чем впечатляют

Какой вы впечатлительный.

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

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

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

Чем fn хуже def, например?

def длиннее и привычнее (Python, Ruby). Да и выделяется в тексте лучше, чем fn.

Неужели так сложно понять, что происходит тут: fn first_of_any(list : &'persistent [i32], values_to_find : &'temp [i32]) -> &'persistent i32 {...

Тут не сложно. Боюсь, только, что это далеко не весь код на Rust-е, который был написан в мире к данному моменту.

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

Это пример из документации

Версии 0.12? Вот текущая: https://doc.rust-lang.org/nomicon/lifetimes.html

Ну, в Go тоже любители лаконичной записи

Ну у него тоже все не просто, даже несмотря на примитивность языка. К примеру:

func (l *List) insertValue(v interface{}, at *Element) *Element {
Я вообще хз, что тут происходит.

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

Версии 0.12? Вот текущая: https://doc.rust-lang.org/nomicon/lifetimes.html

Полагаю, в документации к версии 0.12 мне нагло соврали? А в новой-то лепота и благолепие:

'a: {
    let mut data: Vec<i32> = vec![1, 2, 3];
    'b: {
        // 'b is as big as we need this borrow to be
        // (just need to get to `println!`)
        let x: &'b i32 = Index::index::<'b>(&'b data, 0);
        'c: {
            // Temporary scope because we don't need the
            // &mut to last any longer.
            Vec::push(&'c mut data, 4);
        }
        println!("{}", x);
    }
}

Я вообще хз, что тут происходит.

Странно, про синдром утенка у других вам это не мешает говорить.

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

А в новой-то лепота и благолепие:

Это искусственный пример. Такой код не соберётся.

Странно, про синдром утенка у других вам это не мешает говорить.

Каким боком вы это тут увидели? Я о том, что не зная языка - все новые конструкции будут непонятны. И rust тут не исключение.

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

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

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

Полагаю, в документации к версии 0.12 мне нагло соврали? А в новой-то лепота и благолепие

Это пример неработающего кода с подробными объяснениями, почему он не работает, и полным desugaring'ом. В настоящем коде это выглядело бы так (и всё равно бы не работало):

let mut data = vec![1, 2, 3];
let x = data[0];
data.push(4);
println!("{}", x);
anonymous
()
Ответ на: комментарий от anonymous

Там

let mut data = vec![1, 2, 3];
let x = &data[0];
data.push(4);
println!("{}", x);

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

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

Да, в бэкенде. В основном фикшу баги для архитектуры MSP430, в том числе для того чтобы под нее можно было на расте писать.

А код clang я даже не смотрел, хотя могу представить что там творится, ведь его писали люди которые знают С++ :)

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

Это искусственный пример. Такой код не соберётся.

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

Ну, давайте еще один пример из документации:

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
Количество одно-двух-трехсимвольных значимых символов вам кажется нормальным?

Каким боком вы это тут увидели?

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

Я о том, что не зная языка - все новые конструкции будут непонятны. И rust тут не исключение.

Спасибо, Кэп. Объясните мне пожалуйста, почему знакомясь с Go, Ceylon, Kotlin, Eiffel и пр. языками, после беглого знакомства с описанием языка, код на этих языках оказывается вполне себе понятным и читабельным, а вот при чтении Rust-а приходится запинаться на каждом апострофе?

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

Объясните мне пожалуйста, почему знакомясь с Go, Ceylon, Kotlin, Eiffel и пр. языками

Потому что это языки с GC. Ваш Кэп.

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {

Ок, предложи твой синтаксис для этой строчки

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

Тем не менее, такой пример дают тем, кто изучает Rust для того

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

Количество одно-двух-трехсимвольных значимых символов вам кажется нормальным?

Не имею никаких претензий. В других языках тоже полно коротких ключевых слов. Даже в вашем любимом C++: int, char, struct, decltype.

код на этих языках оказывается вполне себе понятным и читабельным

Я уже 10 раз сказал - это языки с GC. Им нет необходимости указывать время жизни объекта. Или ваш кругозор не позволяет до этого догадаться?

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

Потому что это языки с GC. Ваш Кэп.

Блин, ну возьмите древнюю Ada, Object Pascal/Delphi, современный Swift. Языки без GC.

Ок, предложи твой синтаксис для этой строчки

Это ничего не изменит.

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

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

при чтении Rust-а приходится запинаться на каждом апострофе

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

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

Не понятно другое

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

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

Swift. Языки без GC

там ARC гвоздями прибит, и Swift - не системный язык, если тебе нужен перфоманс на iOs/OSX ты пишешь на плюсах или си, такие дела да

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

Даже в вашем любимом C++: int, char, struct, decltype.

С тех пор, как популярность C превысила популярность наследников Algol-а, int, char и struct стали де-факто стандартами, потеснив integer, character и record.

Но нашлись те, кто решил, что int32_t — это слишком длинно, поэтому нужно i32.

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

Мой кругозор не в курсе границ вашего скудоумия. Давайте добавим к списку такие языки без GC, как Ada, Object Pascal и новый Swift. В Swift-е закорючек тоже хватает, но там это как-то вменяемо умудрились сделать.

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

В Swift есть GC. Своеобразный, но GC. Заботится о памяти там не нужно.

В паскале вообще глобальные переменные и нет указателей и ссылок (насколько я помню).

почему, когда кто-то говорит, что ему не нравится в Rust-е и что ему мешает в Rust-е, так сразу же Rust-оманы как с цепи срываются?

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

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

В паскале вообще глобальные переменные и нет указателей и ссылок (насколько я помню).

Вы бы это, поосторожнее с демонстрацией своих познаний вне мира Rust-а. А то у вас то исключения из конструкторов в C++ оставляют объект наполовину инициализированным, то указателей в Pascal нет.

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

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

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

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

При беглом просмотре кода хорошо было бы более четко видеть границы функций. fn этому не сильно помогает.

При внимательном прочтении кода выясняется, что куча одно-двух буквенных вещей имеют важное значение. Например, &'a или &mut вместо &.

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

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

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

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