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)

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

наверное можешь указать нам с высоты на лучшую альтернативу?

Ну вот как с вами общаться?

Вот, например, AntonyRF и ckotinko в этой теме сказали, что у Eiffel-я синтаксис говно. Ну OK. Люди вообще не знают Eiffel-я, но высказать свое мнение по поводу его синтаксиса считают возможным.

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

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

Вот нахрена это все? Ну не нравится какому-то чуваку синтаксис, ну и что это изменит? Ведь ничего.

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

Я (лично я) думаю, что непохожесть Rust-а на другие широкораспространенные языки отдаляет тот светлый момент, когда начало нового большого проекта на Rust-е не будет столь рискованным мероприятием, как сейчас. Рискованным по совокупности факторов: наличию большого количества библиотек, наличию специалистов на рынке труда, инструментария (вроде IDE), книг, ресурсов и пр.

Имхо (ИМХО, блин), будь Rust более похож на C++ или на Haskell или на любой другой язык, к которому уже привыкли, проникновение Rust-а в индустрию шло бы более быстрыми темпами.

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

Только вот местным растоманам же нельзя это имхо просто проигнорировать. Нужно возбудиться. Причем возбудиться нужно каким-то маргиналам, вроде RazrFalcon, который регулярно несет бред про C++, а в данной теме отметился эпическим высказыванием про отсутствие указателей в Паскале. Или AntonyRF, который всерьез утверждает, что ООП — это отстой, хотя явно мало что знает про ООП и его применимость в тех или иных отраслях.

Ну ладно, у вас на меня уже идиосинкразия, но тут же тов.umren вполне разумные вещи говорил про текущую ситуацию в областях обработки аудио и игростроении. Разве его слова нормально воспринимали? Ему тут народ активно доказывает, что Rust уже вот-вот и вытеснит плюсы из этих ниш. Ну просто потому, что Rust рулез, а C++ отстой. И возражения umren-а о том, каких капиталовложений это потребует, никто не слушает.

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

нет он про указание типа

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

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

Потому, что, на мой взгляд, Rust сильно отличается от мейнстрима

Я сейчас на свифте программирую. Тоже отличается от c++, java и прочего «старого» мейнстрима. Но ничего, все привыкли. Мейнстрим - это такая изменчивая штука.

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

Это вы, кстати, зачем-то уменьшили множество до C++/Rust/Java/C#. Добавьте к этому списку Scala, Python, Ruby, Haskell, OCaml, Erlang и пр.

Зачем? Как я уже объяснил, копировать синтаксис другого языка имеет смысл либо если он хорош, либо если он привычен целевой аудитории. Кому вообще привычен синтаксис Скалы? Полутора человекам? Много ли народу перейдут на раст с питона или руби? Если и перейдут, им придётся кардинально привычки менять, другой синтаксис лямбд будет меньшей из их проблем.

Если в 2005-2006 было два разных пропозала, значит тезис об «более-менее устаканился» не подтвердился. В чем я и не сомневался.

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

Какие здесь растоманы нежные. Кому-то не нравится синтаксис Python-а, кому-то не нравится синтаксис Ruby, кому-то не нравится синтаксис C++, кому-то не нравится синтаксис Eiffel-я.

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

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

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

Может и так. Но box синтакс вместо Box::new() давно пора

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

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

Это ваша личная точка зрения. Я с ней просто не согласен. Поэтому доказывать что-то исходя из нее считаю бессмысленым.

Хотите продолжать доказывать, что код на Расте сложно читать - аргументируйте

Дяденька, вы дурак? Когда кто-то говорит, что ему тяжело пешком подниматься на 5-й этаж, ему нужно доказывать это аргументированно? Мол, пульс такой-то, давление такое-то, количество мышечных спазмов такое-то, уровень болей в суставах такой-то?

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

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

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

Например некоторым не нравится знак `=>` в match. Они хотят чтобы было `:` как в сишке. Но смысл то у них разный. Если будет си подобный синтаксис, то кто-нибудь обязательно напишет такое:

fn main() {
    let FOO: u8 = 10;
    let BAR: u8 = 13;

    switch (13) {
        FOO:
            println!("FOO");
        BAR:
            println!("BAR");
        _:
            println!("Other");
    }
}
И будет очень удивлен что этот код выводит «FOO»

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

Опять же вебу ненужен очередной IE6.

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

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

вообще проблема спецсимволов в эпоху юникода - это скорее проблема клавиатур. ну вот посмотрите на неё: сколько там символов можно набить за 1-2 клавиши? ага.

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

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

По поводу i32. Вам, наверное, мало приходилось видеть кода от хардкорных математиков

Пускай они хороши как математики(хотя не факт), но как программисты они говнокодеры.

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

Это блок из 100500 строк? В 5 строках даже по одной букве понятно что где, просто по тому что они у тебя перед глазами.

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

Емнип в ruby несколько похожий синтаксис.

Я уже здесь показывал синтаксис лямбд из Ruby. Он лучше Rust-ового тем, что рам есть либо открывающая do, либо открывающая {.

В Rust-е же когда сталкиваешься с || -> Result<()>, то слегка офигеваешь. Равно как и вот в таких случаях:

rayon::join(|| qsort(less),
   || qsort(greater));
Как-то не сразу приходит понимание, что здесь две(!) лямбды без параметров. В каком-нибудь другом синтаксисе это было бы для меня более очевидно:
rayon.join(() => qsort(less), () => qsort(greater))
или
Rayon::join lambda {qsort(less)}, lambda {qsort(greater)}

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

Пускай они хороши как математики(хотя не факт), но как программисты они говнокодеры.

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

Это блок из 100500 строк?

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

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

Это ваша личная точка зрения. Я с ней просто не согласен.

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

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

Вот видите, вы опять врёте. Доказать, что на 5й этаж подниматься тяжело очень даже можно. Одышкой, пульсом и так далее. Можно доказать и научно, посчитать там, например, энергию, сравнить с дневной нормой и т.п. Не доказывают, потому что всем это очевидно, даже тем, кому лично не так тяжело. У нас тут иначе, всем пофиг, никто толком не может понять, чего в этом синтаксисе сложного и даже вы ничего внятного придумать не можете.

khrundel ★★★★
()

столько ЯП всяких, Вавилон какой-то.

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

А мне насрать на ваше согласие.

Тогда зачем вы продолжаете мне отвечать?

Вот видите, вы опять врёте.

Да вы и вправду дурак.

eao197 ★★★★★
()

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

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

Вот, например, AntonyRF и ckotinko в этой теме сказали, что у Eiffel-я синтаксис говно. Ну OK
Мне нет смысла доказывать им, что у меня другое мнение на этот счет.

Ну а почему у нам не может быть плохого мнения о Eiffel-е? =) Я своё виденье тоже не навязываю.

Или AntonyRF, который всерьез утверждает, что ООП — это отстой, хотя явно мало что знает про ООП и его применимость в тех или иных отраслях.

Ну вообще-то, что ООП отстой я не говорил. Я сказал, что по скорости разработки между процедурным стилем и ООП нет и, кстати, я работаю с проектом овер 800kloc напичканным ООП. В аргумент я приводил внутреннее исследование IBM, (которое было для IBM, а не для срача) что разницы в скорости разработки нет. Но Вы сказали, что это исследование не достоверное. После я предположил, что IBM не авторитетная шарашка для Вас и решил не продолжать этот спор =)

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

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

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

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

Ну а почему у наC

очепятка

процедурным стилем и ООП нет

разницы

Пардон за очепятки, спешу, бегу, но срачь не утихает =)

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

Ну а почему у нам не может быть плохого мнения о Eiffel-е?

Потому, что с высокой долей вероятности вы ничего об Eiffel-е не знаете.

Ну вообще-то, что ООП отстой я не говорил.

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

кстати, я работаю с проектом овер 800kloc напичканным ООП.

Перепишите его с помощью процедурного подхода, может мнение об исследованиях IBM для аж 19-ти проектов, у вас и поменяется.

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

Вот, кстати, идея на миллион. Написать скриптовый язык, который транслируется в MIR и имеет доступ ко всей стандартной библиотеке. Есть интерпретатор MIR https://github.com/solson/miri так что можно и конпелять и не конпелять

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

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

Тебе что, на планшете это клавиатуре набирать?

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

Тогда зачем вы продолжаете мне отвечать?

Затем, чтоб продемонстрировать слабость вашей позиции. 3 сообщения назад, чтоб увидеть её беспомощность нужно было читать, вникать. Сейчас вот очевидно и так.

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

либо сразу либо сперва у нее перестают перерисовывать фрагменты страницы либо страница скролится без перерисовки -как бесконечная замкнутая лента.

Это просто пример красоты недомногопроесссности фокса.

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

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

Данный код просто интуитивно понятен. Вот просто наверняка что это записано именно замыкание, при этом указан возвращаемый тип.

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

Данный код просто интуитивно понятен.

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

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

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

должно быть соблюдено хотя бы одно условие - на расте движок работает быстрее (минимум раза в 2) потребляя меньше ресурсов

Давно программы на плюсах стали оптимизированние программ на ассемблере? Тогда где движки на ассемблере?

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

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
Ок, предложи твой синтаксис для этой строчки

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

Вот это <'a> как будто бы ненужно, -> тоже

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

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

Не так давно была новость, про то как junior следуя инструкции по настройке dev сервера убил продакшин. Я думаю ты понял на что я намекаю.

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

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

Вот на этом и строится безопасность многопоточности.

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

Я всё жду не наркоманского примера наследования, но видимо не дождусь

Подробнее плиз, а то нет возможности следить за всеми сообщениями в теме

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

Здесь

Нет, там нету, вы ошиблись.

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

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

Выглядят они как навелосипеженный планировщик

Это и есть он, хорошо работающий в конктерном случае, в конкретной утилите.

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

С каких пор полное ключевое слово стало сахаром?

Само наличие слов function\procedure является синтаксическим сахаром, например в Си нет ключевых слов которые говорили бы о начале функции, сразу пишется возвращаемый тип и её имя с параметрами. Ну вы поняли.

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

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

А я, конечно же, просто так это сделал, без профилировки и бенчмарков, по вашему?)
Ну загляните в историю коммитов чтоли

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

Само наличие слов function\procedure является синтаксическим сахаром

Не является, почитай что такое сахар.

например в Си нет ключевых слов которые говорили бы о начале функции

А в питоне фигурные скобки не нужны, однако они - не сахар.

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

Только такой вариант не будет работать.

<'a> - определение, &'a - использование

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

-> тоже

Это сломает описание предикатов:

fn stuff<P>(p: P) -> bool
    where P: Fn() -> bool

fn stuff<P: Fn() -> bool>(p: P) -> bool

///

fn stuff<P>(p: P) bool
    where P: Fn() bool

fn stuff<P: Fn() bool>(p: P) bool
Намного проще читается? Я сомневаюсь.

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

Он лучше Rust-ового тем, что рам есть либо открывающая do, либо открывающая {.

Для однострочных лямбд открывающие скобки ненужны.

Как-то не сразу приходит понимание, что здесь две(!) лямбды без параметров

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

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