LINUX.ORG.RU

Rust 1.36

 


1

9

Команда разработчиков с радостью представляет вам Rust 1.36!

Что нового в Rust 1.36? Стабилизирован трейт Future, из нового: крейт alloc, MaybeUninit<T>, NLL для Rust 2015, новая реализация HashMap<K, V> и новый флаг --offline для Cargo.

А теперь подробнее:

  • В Rust 1.36 наконец-то стабилизировали трейт Future.
  • Крейт alloc.
    Начиная с Rust 1.36, части std, которые зависят от глобального аллокатора (например, Vec<T>), находятся в крейте alloc. Теперь std реэкспортирует эти части. Больше об этом.
  • MaybeUninit<T> вместо mem::uninitialized.
    В предыдущих релизах mem::uninitialized позволяла вам обходить проверку инициализации, использовалось это для ленивой аллокации массивов, но эта функция довольно-таки опасна (подробнее), поэтому был стабилизирован тип MaybeUninit<T>, который безопаснее.
    Ну и так как MaybeUninit<T> является более безопасной альтернативой, то, начиная с Rust 1.38, mem::uninitialized будет являться устаревшей функцией.
    Если хотите больше узнать про неинициализированную память, можете прочесть запись в блоге (Alexis Beingessner).
  • NLL для Rust 2015.
    В анонсе Rust 1.31.0 разработчики рассказывали нам о NLL (Non-Lexical Lifetime), улучшении для языка, которое делает borrow checker умнее и более дружелюбнее к пользователю. Пример:
    fn main() {
        let mut x = 5;
        let y = &x;
        let z = &mut x; // This was not allowed before 1.31.0.
    }
    
    В 1.31.0 NLL работал только в Rust 2018, с обещанием, что разработчики добавят поддержку и в Rust 2015.
    Если хотите больше узнать про NLL, можете прочитать больше в этой записи в блоге (Felix Klocks).
  • Новый флаг для Cargo - --ofline.
    В Rust 1.36 стабилизировали новый флаг для Cargo. Флаг --offline говорит Cargo использовать локально кешированные зависимости, для того, чтобы позже их можно было использовать без интернета. Когда нужные зависимости не доступны оффлайн, и если интернет все-таки нужен, то Cargo вернет ошибку. Для того, чтобы предварительно скачать зависимости, можно использовать команду cargo fetch, которая скачает все зависимости.
  • Здесь вы можете прочитать более детальный обзор изменений.

Также есть и изменения в стандартной библиотеке:

Другие изменения Rust, Cargo и Clippy.

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

★★★

Проверено: Shaman007 ()
Последнее исправление: Virtuos86 (всего исправлений: 4)
Ответ на: комментарий от Barracuda72

Из самого распоследнего - много лет в стабильном компиляторе не было возможности сборки standalone бинарников.

Шта?

Причем формально no_std стабилизировали

no_std доступен с 1.6.0 (2016-01-21), но не для бинарей.

Ворох RFC называть «четким планом» очень смело.

Это и не является планом. Над языком работает куча людей. Они разделены на рабочие группы. У каждой свои задачи и цели.

И такая дребедень у них во все поля.

Примеры-то есть?

Например всё.

Очень аргументированно.

Очень и очень многие фишки языка требуют поддержки как минимум со стороны core.

Какие? core умеет чуть менее чем ничего. Это просто набор примитивов и трейтов.

Отдельные куски core (почти все полезные) требуют аллокатора - а это, на секундочку, настроенный и работающий MMU и прочие нетривиальные вещи.

С каких пор core требует аллокатор?

Список можно продолжать бесконечно, но все это вытекает из моего пункта №1 - язык развивается хаотично, без четкой цели, и «системности» во всех смыслах в нем ноль.

То есть вы ничего не понял. Запутались. А виноваты авторы языка. Ну зсб.

язык развивается хаотично

Язык развивается в первую очередь для x86. Я так понимаю что именно это вас с смущает.

Для нее ржа годится.

То есть Rust не подходит для разработки под 8-и битные процы. Так и запишем.

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

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

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

Кстати, написано resource friendly. Что это значит?

Это значит, что непожирает рессурсы, то есть он пожирает чуточку больше, нежели i3status.

Оно меньше жрет ресурсов чем оригинал?

Нет, не меньше. Но из всех статус баров, оно жрет меньше. Оно действительно resource friendly. Один минус-на Debian Stretch не соберется (там старая версия Rust). На Buster-без проблем.

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

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

abcq ★★
()

Новый флаг для Cargo - –ofline.

На этот раз честно-честно?

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

Знание синтаксиса в данном случае — даже не 5% успеха.

Тогда тем более, раз 95% сложности - в предметной области, а не в ЯП, тем более непонятен отказ от сишки со множеством наработок, соглашений, сниппетов... в пользу других ЯП. В контексте железа, которое на порядки слабее 1-й малинки.

P.S. Сам я далеко не сишник. Люблю заниматься только прикладухой.

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

Ну я вот поставил, то у меня жрет 10МБ, не сравнимо конечно ни с чем на python, но таки жирнее i3blocks - 7МБ. Интересно, вот за счет чего

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

проблема неправильно построения и композиции

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

удобство - это когда ты приходишь на расслабоне, херак, херак, и в продакшен - и работает, и надежно, и красиво.

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

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

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

Поэтому дишечка более симпатична. Руст изучать пробовал, не зашло.

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

Раз 95% сложности — в предметной области, то вполне логично использовать ЯП, позволяющий лучше концентрироваться на предметной области, не отвлекаясь на всякую дичь вроде указателей и маллоков.

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

посмотрел 5 минут, плюнул, почитал комменты:

do you like rust or not? sorry just need a TLDR.

TLDR: Rust as language is ok, my 1001 issues are with the compiler implementation, aka compiling from source code for your own system as well as the tightly integrated Cargo build system stuff, mostly for having 100 micro dependencies packages and pulling them in all automatically from the interwebs, and storing GigaBytes of build artefacts (sources and binary data), by default in ~/.cargo

я так понимаю, он полтора часа компиляет исходники раста и ругает его за то, что так долго компиляется

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

теги вообще смешные поставил: #apple #ssd

короче, все заходим, поднимаем просмотры

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

не отвлекаясь на всякую дичь вроде указателей и маллоков

Это когда железо позволяет запускать ОС. А если вызывать malloc физически невозможно, вся память выделена сразу, libc вообще отсутствует? От языка нужны ветвления, циклы и удобная работа с побитовыми операциями. Что если предметная область находится не «выше», а «ниже» маллоков?

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

А малинка с полноценным линуксом - на много порядков мощнее, можно спокойно пускать node.js.

Я считаю, что js-у место только в прикладухе, где можно не «считать байтики». А раст изначально проектировался под системщину в том числе.

P.S. Когда-то надо будет сесть и ознакомиться с растом ради общего развития. Хотя интуиция подсказывает, что мне не понравится. Зато смогу часть растовых фич «портировать» на мой код на других ЯП. И как только началось обсуждение js-а в новости про раст? Ведь у них разная ЦА.

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

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

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

Ну в разных языках всегда будут разные подходы. Хотя, вспоминая ripgrep, можно придти в выводу, что да проблема в реализации.

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

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

Существуют. https://github.com/hackndev/zinc/blob/master/examples/blink_stm32f1/src/main.rs

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

crate and trait

Трейты полезная штука. Мен пноравилось.

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

У меня опыта на нем где-то год-два. Забросил в декабре 2018 года.

Ради понтов пилю wayland compositor на нем и софтварный 3D рендер. Проекты больше 100 000 строк кода.

Веселье закончилось на слове «многопоточность».

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

В 2016 по 2018 я пишу на расте домашние проекты. Сейчас как-то руки до него не доходят. Ссылок на гитлаб не будет, а жаль! :(

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

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

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

Такие простые во всех смыслах программы являются простыми на любом нормальном ЯП. Продвинутые фишки раста и прочих «не си» раскрываются в больших проектах, а не в таких малютках. И вообще, тот вопрос против js-а в «низком уровне», который не проектировался для этого. А раст изначально пилился в том числе под такие вещи.

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

GC GC рознь.

Тут дело не в нем, а в способе проектирования. То, что прокатывает с прикладным ПО (итерационная разработка), не прокатывает с инструментальным. По сути, это если бы тебе приносили отвертку, каждый раз новой формы и способа эксплуатации.

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

Он не лучше, он другой. И его затачивают как замену сишке. То есть упор на микроконтроллеры.

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

Шта?

Та.

no_std доступен с 1.6.0 (2016-01-21), но не для бинарей

О чем я и говорил.

Над языком работает куча людей. Они разделены на рабочие группы. У каждой свои задачи и цели.

Ну вот. А общей концепции нет и не было.

Примеры-то есть?

Весь Rust - один большой пример.

Какие? core умеет чуть менее чем ничего. Это просто набор примитивов и трейтов.

Как бы не совсем, иначе бы standalone-программы его б за собой не тащили и без него можно было бы жить.

С каких пор core требует аллокатор?

В нем есть как минимум интерфейсы (или трейты, по-вашему) для него. Может быть и не очень удачный пример. Могу привести поудачней: core родительской системы x86_64 не будет работать в no_std окружении (точнее будет, но недолго) из-за того, что некоторые подпрограммы используют SSE/FPU. Удачи в написании загрузчика или ядра ОС. Да, официальный совет - «ну вы пересоберите core под то, что вам надо».

То есть вы ничего не понял. Запутались. А виноваты авторы языка. Ну зсб.

Это, кстати, говорит не в пользу Rust и одна из самых популярных жалоб на него - «непонятно ничерта чего они там накуролесили». И опять же следует из проблемы №1. Запутались там давным-давно сами авторы языка.

Язык развивается в первую очередь для x86. Я так понимаю что именно это вас с смущает.

Меня смущает то, что язык развивается не в первую очередь, а практически исключительно для hosted x86_64, но при этом его почему-то толкают как «системный», хотя для написания ядер ОС и дров даже для того же x86_64 он подходит примерно никак. Нет, написать можно, преодолев горы боли и унижения (люди и на C#, и на VB, и на чем только не пишут), но того факта, что Rust для этого подходит слабо, это не отменит.

То есть Rust не подходит для разработки под 8-и битные процы. Так и запишем.

В том числе. И под любые другие bare metal, хоть 16, хоть 32, хоть 64-битные. Прекратите называть его «системным» и сравнивать с C, поставьте на одну чашу весов с C#/Java и всем будет ЗБС. Собственно, место рже там, где до сих пор из соображений производительности C++, но мозгов кодеров хватает только на Java/C#, типа того же браузера (опять сюрприз).

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

А общей концепции нет и не было.

Только в ваших фантазиях.

Весь Rust - один большой пример.

Аргументация уровня ЛОР.

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

Они есть в alloc, но не в core. В core даже работа с float урезана, а вы про аллокации.

одна из самых популярных жалоб на него

1 человек != популярность.

хотя для написания ядер ОС и дров даже для того же x86_64 он подходит примерно никак.

При этом ядра и дрова на нём пишут. Парадокс.

толкают как «системный»

Системный - вообще размытое понятие.

Прекратите называть его «системным» и сравнивать с C

С Си его никто и не сравнивает. Сравнивают с C++.

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

Видение у разработчиков языка есть, но некоторые вещи вроде embedded в него явно не входит.

1 человек != популярность

Далеко не один человек.

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

Раст, в 95% случаев ругают за синтаксис и сложность. Ругать язык за то, что он не умеет то, для чего не предназначен - как минимум странно.

но некоторые вещи вроде embedded в него явно не входит.

https://github.com/rust-embedded/wg

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

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

Ты удивишься, но нет. Раст скрывает не больше чем Си.

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

core::alloc содержит интерфейс, который надо реализовать чтобы получить возможность использовать Box<T> а следовательно кучу. Без этого у тебя только .data и стек.

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

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

люди и на C#

Кстати, идея написания ОС и userspace н C# или Java проистекает от ограниченого набора инструкций VM. Если запретить арифметику указателей, то отсутствует необходимость защищать процессы от друг друга и ядра посредством разных адресных пространств и копирования. На уровне intermediate кода этим сущностям обычно будет запрещено видеть друг друга. Но в ограниченых, безопасных случаях указатели между user-space и ядром будут передаваться без копирования

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

Но ведь можно использовать rustup

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

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

Я, увы, читал всю документацию, форумы, списки рассылки, issue и RFC и в итоге понял то, что понял. Что Раст непригоден для системного программирования.

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

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

Да, я выбрал не очень удачный пример. Что не отменяет того факта, что этого в core быть _вообще не должно_ и еще раз иллюстрирует концепцию развития «лебедь, рак и щука».

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

Только в ваших фантазиях.

Увы, это суровая реальность.

Аргументация уровня ЛОР.

Ну так.

Они есть в alloc, но не в core. В core даже работа с float урезана, а вы про аллокации.

core::alloc же.

1 человек != популярность.

Тем не менее во всех уголках сети не я это мнение высказываю.

При этом ядра и дрова на нём пишут. Парадокс.

Я, кажется, заметил, что пишут почти на любом ЯП. Что не является показателем его пригодности для данной задачи.

Системный - вообще размытое понятие.

Да, согласен. Потому видимо его и используют для пиара Ржи.

С Си его никто и не сравнивает. Сравнивают с C++.

Да с чем его только не сравнивают... Чаще все-таки с Си, потому что с плюсами Rust сравнивать чревато.

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

Мне кажется, что изоляция здесь все равно потребуется, ибо в этом случае что-нибудь типа того же Meltdown будет сильно проще найти и проэксплуатировать

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