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

Чем это противоречит: «Так что, как минимум, речь может идти только о сравнительной стоимости»?

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

То ли я тупой, то ли не понимаю в чём проблема, вот вам без impl Shape for CircleData

trait Shape {
    fn get_x(&self) -> f64;
    fn get_y(&self) -> f64;
}

struct ShapeData {
    x : f64,
    y : f64
}

impl Shape for ShapeData {
    fn get_x(&self) -> f64 {
        self.x
    }

    fn get_y(&self) -> f64 {
        self.y
    }
}

trait Circle  {
    fn get_radius(&self) -> f64;
}

struct CircleData {
    parent : ShapeData,
    radius : f64
}

impl Circle for CircleData {
    fn get_radius(&self) -> f64 {
        self.radius
    }
}

fn main() {
    let shape: ShapeData = ShapeData{x: 1.0, y: 2.0};
    println!("{}, {}", shape.get_x(), shape.get_y());

    let circle: CircleData = CircleData{parent:ShapeData{x: 1.0, y: 2.0}, radius: 5.0};
    println!("{}, {}", circle.parent.get_x(), circle.parent.get_y());
}

Вот вывод

     Running `target\debug\oop.exe`
1, 2
1, 2

impl Shape for ShapeData - уже объявлен и в этой области видимости ShapeData будут иметь соответствующие методы.

Или я не понял в чём суть проблемы? 0_о

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

Ты спросил есть ли движки — я ответил и привел примеры.

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

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

Сравнительной стоимости чего?

При той же скорости исполнения раст еще и гарантирует отсутствие дата рейсов, юз-афтер-фрии и дабл-фрии. Теоретический ты можешь писать на крестах безопасный код, но можешь и не писать. Или ты можешь писать на крестах безопасный код, но твой сосед может писать не очень безопасный код. Или ты можешь сегодня писать на крестах безопасный код, но завтра придти на работу с похмелья и написать не очень безопасный код. На расте такого нельзя, кроме как в ансейфе, но с ансейфом все просто: https://pbs.twimg.com/media/DCUEBleUQAAqBU9.jpg .

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

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

Ну так соорудить компилятор с интегрированным единорогом - реально. Вроде как есть уже подобные (ну типа hol и acl2). Не то еще конечно, но тем не менее...

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

Сравнительной стоимости чего?

Сравнительной стоимости разработки многопоточного софта. Особенно с учетом того, что зачастую оный на плюсах пишется с использованием готовых инструментов, вроде OpenMP, TBB, HPX и пр.

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

Благодарствую!

Первый баг исправил и тут же перестало работать. Второй исправил - работает и уже без той переменной.

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

Я не «за» и не «против» раста. Я хочу дать языку шанс. Я там пишу 3д движок с софтварным рендером и вот решил переписать на ржавчину без unsafe, без Box, без большого количества unwrap используя сематнику владения, копирования и перемещения. Если получится, то ржавчина завует мою симпатию. Если нет, то теперь буду знать за что критиковать.

Плюс, можно сравнивать одинаковый проект но с разными языками.

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

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

Сравнительной стоимости разработки многопоточного софта

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

готовых инструментов, вроде OpenMP, TBB, HPX и пр.

Аналоги которых есть для раста, да.

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

Не вижу почему на расте дожно быть больше

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

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

Аналоги которых есть для раста, да.

Можно список? Начиная прямо с OpenMP.

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

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

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

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

Можно список?

https://github.com/nikomatsakis/rayon https://github.com/crossbeam-rs/crossbeam

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

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

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

И я не говорил, что стоимость разработки многопоточного приложения на Rust будет выше. Это еще проверять нужно. Пока что по своим фичам именно в плане многопоточности Rust не впечатляет от слова совсем.

https://github.com/nikomatsakis/rayon https://github.com/crossbeam-rs/crossbeam

Да здесь все как и с движками для игр, как я посмотрю. OpenMP, простите, где?

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

Вообще, глупый спор.
Ты ещё от сишечки такого потребуй.
В Расте нет классов, соответственно нет наследования реализаций и данных, есть только наследование интерфейса.
Всё.
Но можно из..ся.
https://rustycrate.ru/обучение/2017/06/11/oop-in-rust.html

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

OpenMP, простите, где?

Тебе шашечки или ехать? На двое 2017 год, современные языки могут в дата параллелизм через библиотеки, без нестандартных хаков прямиком из 90х.

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

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

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

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

без агрегирования наследование невозможно? Чтоб просто написать circle.get_x()?

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

Не знаю как проще сказать

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

MPI это совсем другая история, вот тебе биндинги https://github.com/bsteinb/rsmpi , вычисляйся сколько хочешь. OpenMP же это грязный хак, который был добавлен в няшную по причине ее убогости. В современных языках ему места нет, т.к. все можно и нужно реализовывать в библиотеках.

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

А в Haskell типы выводятся и гарантируется оптимизация рекурсии. Что дальше?)

Это другая парадигма и подходы к разработке другие

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

OpenMP же это грязный хак

Ясно, чего (пока) нет в Rust, то не нужно.

Даже если согласиться с этой идиотской точкой зрения, это будет означать, что там, где сейчас OpenMP используют совместно с Fortran-ом, C и C++, Rust не появится... Ну никогда, наверное.

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

И то, что стоимость написания многопоточного кода на C++, местами, будет сильно ниже, чем на Rust-е.

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

Ну давай, объясни мне, в чем превосходство OpenMP над библиотечным подходом, и почему нестандартное расширение над языком - это лучший способ добавления функциональности. Ты наверное и от C++/CX фанатеешь?

там, где сейчас OpenMP используют совместно с Fortran-ом, C и C++, Rust не появится... Ну никогда, наверное.

Не вижу как ты к этому пришел. OpenMP это не MPI, ты можешь переписать кусок на rayon или crossbeam и заинтегрить его в общий воркфлоу.

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

Не вижу как ты к этому пришел.

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

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

И как же многолетние дебилы объясняют тот факт, что не все в мире написано на фортране? Казалось бы, зачем использовать новые языки, когда можно переиспользовать существующий код.

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

ещё не говорит о том что это будут делать

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

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

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

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

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

Вопрос от типичного малолетнего дебила (с).

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

Какой еще идиотский вопрос вы зададите?

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

Какой еще идиотский вопрос вы зададите?

Зачем ты переиспользуешь код на уровне исходников?

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

Почему ты тратишь столько времени посреди рабочего дня на то, чтобы кричать НЕНУЖНО в лоровских тредах про раст?

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

Зачем ты переиспользуешь код на уровне исходников?

Это дешево.

Почему писать на крестах

Потому, что знаю, как это делать быстро, недорого и не больно.

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

У меня сейчас много полных тестовых прогонов. Компиляция тестов с Asio и Catch-ем занимает очень много времени.

Еще идиотские вопросы будут?

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

А эти 100500 ссылок, врапперов итд. Кому-то это правда нравится?

Как минимум, отторжения не вызывает. Альтернатива - делать автоматические приведения и отключать их при помощи explicit - те же яйца только в профиль.

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

Но то, что имя типа может быть как перед ":", так и после, внушаить.

А где в коде выше имя типа перед двоеточием?

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

В к примеру c# мне не нужно дважды реализовывать. Мне достаточно написать class B : A {} И всё готово.

Напиши небольшой пример на C#, а люди подскажут как это делается в Rust.

use std::ops::Deref;

struct Shape(f32, f32);

impl Shape {
    fn get_x(&self) -> f32 { self.0 }
    fn get_y(&self) -> f32 { self.1 }
}

struct Circle(Shape, f32);

impl Circle {
    fn get_radius(&self) -> f32 { self.1 }
}

impl Deref for Circle {
    type Target = Shape;
    fn deref(&self) -> &Shape { &self.0 }
}

fn main() {
    let circle = Circle(Shape(10.0, 20.0), 5.0);

    println!("x={}", circle.get_x());
    println!("y={}", circle.get_y());
    println!("radius={}", circle.get_radius());
}
anonymous
()
Ответ на: комментарий от AntonyRF

Наследования не существует

Как может существовать ооп без наследования?

то алгоритмы не знают какой тип к ним попал

возможно несколько наивный вопрос, а за чем алгоритмам знать какой тип к ним попал?

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

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

А какие крупные компании уже поставили себе эту утилиту?

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

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

ООП разное есть. Есть на классах как в решетке(C#), есть прототипное как в луне(Lua), есть на примесях как в скале или в растишке с помощью типажей.

Наследование в расте как в плюсах нет. Но есть наследование для типажей.

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

Тут про ооп говорили что оно есть, но его нет Rust 1.18 (комментарий)

Точной формулировки, что такое ООП в мире - нет. На самом деле конкурирующих формулировок много и по некоторым из них получается, что Rust язык с ООП Пруф

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

Нет, все и так понятно.

Тогда объясните, пожалуйста, мне: как можно переиспользовать код на C++ иначе, чем на уровне исходников? Да и не только на C++. Еще про Ruby, например, тоже будет интересно узнать.

eao197 ★★★★★
()
Ответ на: комментарий от anonymous
self.0
self.1

Информативно. Давно о таком мечтал. Предлагаю не ограничиваться полумерами, а вернуться к программированию напрямую в машинных кодах.

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

без агрегирования наследование невозможно? Чтоб просто написать circle.get_x()?

да пожалуйста!

https://play.rust-lang.org/?gist=629d8f3d3759d1ccdf7830385ff136d7&version...

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