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

В твоих фантазиях?

То что что-то происходит редко ещё не позволяет отрицать это.

В отличии от хрома она ещё и память не охотно возвращает.

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

я бы тоже самое и про всякие u32 сказал.

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

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

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

Просто не надо пихать рекурсию для поиска 100500 элемента массива, если не поддерживается оптимизация.

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

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

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

u32 это еще можно неплохо расшифровать как unsigned 32, как и другие сокращения. А вот нагромождение двоеточий, синтаксиса лайфтаймов (всякие там '<>) и получающаяся потом каша типа '<T<Box<T<Box'a'b'c>>::d(); действительно пугает.

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

Но я видел некие упреки в сторону хаскелла по этому поводу, мол алгоритм сортировки плохой.

https://habrahabr.ru/post/317348/

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

Не хвостовую рекурсию попробуй оптимизируй

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

я бы тоже самое и про всякие u32 сказал.

unsigned int на много понятниее?

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

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

Так вопрос в том нужно ли считать баги и недокументированные возможности «совместимостью». Если нет, то никто ничего и не сломал.

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

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

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

Тогда уж так:

(let (is_divisible_by lhs rhs) (eq? (mod lhs rhs) 0))

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

По всем пунктам согласен.

Но когда я вижу C++ код с перегруженными операторами - блевать хочется куда сильнее, потому что такие вещи - это просто удар под дых: ты анализируешь чужой код и думаешь, что «>>» сдвигает значение на N бит вправо? А ни(чего) подобного, оно вызывает специальный «шифрующий» обработчик на значении объекта. А какой-нибудь * вдруг начинает матрицы бодро перемножать. Вообще за все эти быдлохакерские модификации синтаксиса языка находу, провозглашающие, что «С++ - это просто средство создания собственного языка с элементами б и ш» - надо бы расстреливать.

ИМХО у языка R нормальный синтаксис, но... его разрабатывали люди науки, что многое объясняет и является причиной в общем-то и всех недостатков, среди которых ключевой - в том, что в «неклеевом» режиме работы R просто адски медленный, разве что быстрее bash'а какого-нибудь. Т.е. при очень грамотном синтаксисе R откровенно сливает на всех «штучных» операциях, поскольку будучи синтаксически отличным императивным языком - технически это всё ещё ограниченный язык для работы с матрицами и датасетами.

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

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

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

Ну серьезно, язык придумали тупые школьники

Агрументация просто от бога и совсем без перехода на личности

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

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

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

Pascal-like, одни из самых продуманных по синтаксису языков. ML-like чуть лучше, но у них концепция другая.

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

Разве R императивный? Это же Array programming (есть невзрачный термин векторное программирование). Ну, а проигрывает ибо интерпретируемый и из-за отсутствия развитой системы тех же зависимых типов смешать собственно скаляры, многомерные и прочая, хотя можно было бы оптимизировать.

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

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

Так добавь присвоение после имени типа, современные компиляторы позволяют объявлять переменные прямо в теле методов.

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

А что плохого в перемножении матриц? Со сдвигом соглашусь (и то, что в стандартной библиотеке битовым сдвигом вводят-выводят, имхо, очень неправильное решение), а с умножением — по-моему это то, ради чего перегрузка операторов и нужна. Я в Java писал всякие plus и multiply для BigDecimal-ов, ничего хорошего в этом нет, перегрузка тут очень в тему.

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

Зачем использовать C++, если есть Rust?

Втопку ржавчину, на хаскле и то проще кодить. А вообще тупиковая ветвь развития ЯП. Что-то вроде pvs studio - более верный подход к надежности кодинга.

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

R --- это инфиксная Scheme для работы с данными. Большая часть «паттернов» Lisp/Scheme, отлично реализуються в R. Офф. Мне он тоже нравиться.

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

Да, Haskell как-то попроще Rust'а будет. Но статический анализатор спасет лишь от весьма простых ошибок. Нужна формальная верификация.

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

я думал, что мы живем в эпоху неограниченной памяти

Память бывает разная. В компьютерном магазине ее много и она дешевая, у хостера, где работает приложение уже совсем не дешевая, хотя ее много, а если вспомнить, что CPU с кешем работает в 20 раз быстрее, чем с плашками памяти, то размер памяти 32+32К.

Так что память@localhost она дешевая и ее много, в остальных случаях уже не дешевая или ограниченная.

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

R --- это Лисп для обработки данных с более привычным синтаксисом (который для Лиспа хотели сделать, но не сделали)

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

А какой-нибудь * вдруг начинает матрицы бодро перемножать

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

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

Меряться гибкостью мышления лучше всего на олимпиадах

Меряться-то, конечно, лучше на олимпиадах. Для того они и придуманы.

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

anonymous
()

Эм, а не лучше по поводу упорядочивания u8, u16, u8 как в примере сообщить программиста? Мол так и так-то, вы сможете экономить память, если поменяете расположение вот так-то и так-то. А то как-то пугает такое решение вида темных операций. Хотя сейчас и компилятор не знает об организации процессора много да и вообще. Всё усложнено.

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

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

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

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

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

по-моему это то, ради чего перегрузка операторов и нужна.

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

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

Синтаксис надо максимально упростить и сделать однородным

Lisp?

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

использующие перегрузку операторов

Без нее template не имеет смысла.

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

Фтопку эти скобочки. Не гармонируют с клетчатой рубашкой. Даешь создание скопов отступами и вызов функций как в хаскеле!

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

Это синтаксический сахар уже.

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

А что не так с вызовом функций как в хаскелле? И чем они принципиально отличаются?

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

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

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

Нельзя, деньги на бухло кончаются быстро.

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

Целевую функцию надо тогда определить что значит zaebis.

Ящитаю, компилятор сам может вывести.

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

fn is_divisible_by(lhs: u32, rhs: u32) -> bool {

Зачем две точки в параметрах? Вот какую практическую цель они несут? Почему другие языки без них обходятся? Зачем добавлять ненужные сущности?

Как написать это?:

fn fun(lhs: u32, rhs: u32, uhs: f32, ohs: f64) -> bool {

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