LINUX.ORG.RU

Вышел Rust 1.20

 


2

7

Команда разработчиков Rust с удовольствием объявляет о выходе новой стабильной версии Rust: 1.20.0.

Rust — это язык программирования, ориентированный на безопасность, скорость и параллелизм.

Если у вас установлена предыдущая версия Rust, то для обновления до Rust 1.20 достаточно выполнить следующую команду:

rustup update stable

(Прим. пер. - иногда предварительно нужно выполнить rustup self update)

Если Rust ещё не установлен, то вы можете установить его скачав rustup с соответствующей страницы на нашем сайте. Также вы можете посмотреть полный список изменений в Rust 1.20.0 на GitHub.

Что нового в стабильной версии Rust 1.20.0

В предыдущих версиях Rust вы уже могли определять «ассоциированные функции» для трейтов, структур и типов-сумм:

struct Struct;

impl Struct {
    fn foo() {
        println!("foo - это ассоциированная функция структуры Struct");
    }
}

fn main() {
    Struct::foo();
}

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

В Rust 1.20 добавлена возможность использовать «ассоциированные константы»:

struct Struct;

impl Struct {
    const ID: u32 = 0;
}

fn main() {
    println!("ID структуры Struct: {}", Struct::ID);
}
Здесь константа ID ассоциирована со структурой Struct. Как и функции, ассоциированные константы могут быть определены для трейтов и типов-сумм.

Использование ассоциированных констант в трейтах предоставляет дополнительные возможности. Ассоциированная константа в трейте используется также, как и ассоциированный тип: её можно определить, не присваивая ей значение. Значение константы будет указано при реализации трейта:

trait Trait {
    const ID: u32;
}

struct Struct;

impl Trait for Struct {
    const ID: u32 = 5;
}

fn main() {
    println!("{}", Struct::ID);
}
В предыдущих релизах Rust при реализации трейта, представляющего числа с плавающей точкой, приходилось писать такой код:
trait Float {
    fn nan() -> Self;
    fn infinity() -> Self;
    ...
}
Это немного неудобно, но, что более важно, такие функции невозможно использовать для определения констант. Из-за этого приходилось вводить дополнительные константы:
mod f32 {
    const NAN: f32 = 0.0f32 / 0.0f32;
    const INFINITY: f32 = 1.0f32 / 0.0f32;

    impl Float for f32 {
        fn nan() -> Self {
            f32::NAN
        }
        fn infinity() -> Self {
            f32::INFINITY
        }
    }
}
Ассоциированные константы позволяют реализовать всё это намного проще. Трейт будет выглядеть таким образом:
trait Float {
    const NAN: Self;
    const INFINITY: Self;
    ...
}
А его реализация станет намного проще и расшит возможности использования трейта:
mod f32 {
    impl Float for f32 {
        const NAN: f32 = 0.0f32 / 0.0f32;
        const INFINITY: f32 = 1.0f32 / 0.0f32;
    }
}
Ассоциированные константы были предложены три года назад в RFC 195. И мы наконец смогли их реализовать! Этот RFC содержал все виды ассоциированных элементов, не только константы. Некоторые из них мы смогли реализовать быстрее чем другие. Мы много работаем над улучшением поддержки работы с константными выражениями, чтобы увеличить возможности Rust в области мета-программирования во время компиляции. В будущем в этой области появятся дополнительные возможности.

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

Стабилизация библиотек

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

Макро unimplemented! теперь принимает параметр, в котором можно указать причину отсутствия реализации.

Добавлена поддержка Unicode 10.0.0.

Функции min и max были переписаны на Rust, и больше не используют cmath.

Внедрена защита от уязвимости Stack Clash. Основные изменения: stack probes и отключение дополнительных ручных проверок для стека основного потока. Для включения защиты достаточно скомпилировать проект в Rust 1.20, изменения в коде не требуются.

В стандартную библиотеку добавлены три новые функции сортировки: slice::sort_unstable_by_key, slice::sort_unstable_by и slice::sort_unstable. Как вы заметили, все три содержат «unstable» в названиях. Стабильность — это свойство алгоритма сортировки, которое требуется не всегда, но раньше в стандартной библиотеке не было алгоритмов нестабильной сортировки. Теперь доступны обе возможности! Для демонстрации разницы между этими видами сортировки рассмотрим список:

rust
crate
package
cargo
Список, отсортированный алгоритмом стабильной сортировки только по первой букве, должен выглядеть таким образом:
crate
cargo
package
rust
То есть, если в исходном списке слово crate предшествовало слову cargo, то и в отсортированном списке оно должно стоять первым. Алгоритм нестабильной сортировки тоже может выдать такой результат, но допускается и вариант с измененной последовательностью:
cargo
crate
package
rust
Как вы понимаете, меньшее количество ограничений часто позволяет создать более быстрый алгоритм. Если вам не важна стабильность сортировки, нестабильная сортировка может оказаться быстрее, чем стабильный вариант. Как обычно, лучше попробовать оба варианта и сравнить их скорость. Эти функции сортировки были добавлены в RFC 1884. По ссылке вы можете узнать больше подробностей, включая результаты бенчмарков.

Также были стабилизированы следующие API:

и некоторые другие.

Возможности cargo

Этот релиз внес полезные улучшения в менеджер пакетов cargo. Первое и самое важное: токен аутентификации для crates.io хранился в ~/.cargo/config. Обычно маска доступа для файлов конфигурации устанавливается в 644, то есть чтение разрешено всем. Но в этом файле хранится секретный токен. Мы переместили токен в отдельный файл ~/.cargo/credentials, таким образом для него может быть установлен доступ 600, и он будет скрыт от других пользователей системы.

Если вы использовали пакеты Cargo, создающие дополнительные исполняемые файлы, вы знаете, что их исходный код хранится в src/bin. Но иногда вам может понадобиться создать несколько дополнительных исполняемых файлов, требующих много кода. В этом случае код может храниться в файлах src/bin/client.rs и src/bin/server.rs и все субмодули этих файлов попадут в один каталог, что неудобно и создает путаницу. Теперь мы используем соглашение, что такие файлы как src/bin/server/main.rs и src/bin/client/main.rs также используются для создания дополнительных исполняемых файлов. Это позволяет удобнее разграничить код.

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

★★★

Проверено: Shaman007 ()
Последнее исправление: red75prim (всего исправлений: 3)
Ответ на: комментарий от anonymous

Че-ж плюсовики то тогда первыми плюются от раста?)

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

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

Этот клоун в каждом треде про раст уже написал про GC.

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

На самом деле Tokio простой как топор

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

В результате имеем глубоко внутри один зоопарк (mio, futures, tokio-*, hyper), а снаружи - совершенно иные абстракции.

Из фреймворков должны торчать типы hyper, tokio-server, которе должны являться общим знаминателем для взаимодействия между разными библиотекамии и фреймворками. А по факту пока имеем разброд и шатание, как в Си, с его сотнями несовместимых друг с другом сетевыми либами

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

А по факту пока имеем разброд и шатание, как в Си, с его сотнями несовместимых друг с другом сетевыми либами

Верно. Но бывает и еще хуже - энтузиасты-разработчики активно запилили кучу вещей в стандартную библиотеку как могли, после чего кто-то из общества сделал вариант получше. В итоге, либо std становится кладбищем, вместо которого нужно использовать «вот-тууу чужую либу», либо раскол как в Питоне 2 и 3.

Куча конкурирующих либ? Пусть конкурируют. Кого в итоге полюбит общество больше прочих тот и заслуживает приз в виде интеграции в стандартную библиотеку. Но не раньше.

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

Куча конкурирующих либ? Пусть конкурируют. Кого в итоге полюбит общество больше прочих тот и заслуживает приз в виде интеграции в стандартную библиотеку. Но не раньше.

А потом появится новая, более лучшая либа, и что делать? Выпиливать предыдущего фаворита из stdlib?

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

А потом появится новая, более лучшая либа, и что делать? Выпиливать предыдущего фаворита из stdlib?

Если библиотека была фаворитом общественности еще до добавления в std, то в своей нише скорее всего она и останется таковой. Другая парадигма - другой разговор (например, если в std синхронная либа, а кто-то потом написал асинхронную).

Если лучше только внутренняя имплементация а не внешний интерфейс, то можно пропатчить std.

Главное, не начать с самого начала пихать в std всякое дерьмо, еще не зная, пройдет ли оно испытание общественности или нет.

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

Не надо вообще тащить ничего в stdlib. Популярные либы просто могут получать какой-нибудь особый статус и промоутиться на crates.io.

Хотя и это излишне. И без статусов с промоутингами все знают, что tokio — самая популярная либлиотека для асинхронщины

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

Я как раз таки упёр с плюсов на ржавчика.

А у тебя есть хотя бы 5 лет опыта коммерческой разработки на C++? Если нет, то я сомневаюсь что ты и знал плюсы до того как «упёр».

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

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

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

Можешь попробовать закомментить их там.

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

export RUSTFLAGS="$RUSTFLAGS -C link-args=-lffi" && CC=clang CXX=clang++ python x.py test
Итог:
test result: FAILED. 2714 passed; 1 failed; 5 ignored; 0 measured; 0 filtered out
99,96323529411764705883% тестов выполнились успешно, но один тест провалился.

Может поэтому Патрик и собирал с системным LLVM, потому что свой не компилится в слаке?

Вероятно. Как и то, что он просто взял слакбилд со slackbuilds.org и начал с ним работать. А слакбилды для slackbuilds.org делают для стабильной ветки Slackware. Релиз же стабильной Slackware 14.2 был в июле прошлого года. Тот же GCC в стабильной Slackware 14.2 версии 5.3.0.

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

Это из личного наблюдения, я еще не видел людей которые ничего не написав (кроме универских лаб) знают C++. Обратное конечно неверно, наличие опыта не гарантирует что человек что-то знает. Но шанс найти знающего среди опытных гораздо выше чем среди студентов.

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

Самокритично. Ну вот ещё, буду я каким-то ноунеймам портфели собирать.

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

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

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

Куча конкурирующих либ? Пусть конкурируют

Э не. Это для обычных либ правдиво. А неблокирующая сетевая либа - вещь ключевая. Вокруг нее языки пишут (go, scala, erlang). Хорошие сетевые неблокирующие абстракции - язык живет. Плохие - нет языка

Сейчас есть низкоуровневая mio (lite аналог libuv) и все согласились, что это стандарт. Поверх нее пошли абстракции сомнительного качества - futures, tokio. И если тут начнутся форки и аналоги - язык загнется. Так как не будет прочного основания для построения серверных приложений. Банально http и websockets сервера от разных разработчиков в один eventloop не встроишь

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

А что за тест провалился?

run-pass/issue-40883.rs ... FAILED
// check that we don't have linear stack usage with multiple calls to `push`
// min-llvm-version 4.0
$ ls /var/log/packages/llvm*
/var/log/packages/llvm-4.0.0-x86_64-1

Expected Result

Function should use a small amount of stack space, definitely less than 2 kilobytes (Big is 512 bytes per copy); 1.12.0 with -Z orbit=off uses 1088 bytes of stack.

Actual Result

When compiled, the function uses more than 16384 = 8*64*16*2 bytes of stack space, as is evident from subq $16384, %rsp in the assembly - 2 copies of Big for every call to push.

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

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

pftBest ★★★★
()

О, тот самый «системный» язык в стандартной библиотеке которого не только файл нельзя ммапнуть но и uds открыть или банально сигнал обработать нельзя. Серьёзно?

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

Ну, раст вообще не тот язык, где можно взять и за 4 года хоть что-то написать

Таки да.

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

О, тот самый «системный» язык в стандартной библиотеке которого не только файл нельзя ммапнуть но и uds открыть или банально сигнал обработать нельзя. Серьёзно?

Можно подумать в стандартной библиотеке С все есть.

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

Приходят в сообщество то в основном всякие рубисты, жабаскриптщики, гоферы

Серьезно? Ну нет, даже палочкой тыкать это нельзя. Понятно теперь почему столько хайпа, а полезного выхлопа 0.

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

Мне не интересен растосрач ввиду довольно плотного графика.

Алсо, после того, как я пообщался с внешними программистами в одном проекте, мне люто хочется заставить их писать на таких языках как:

  • Ada
  • pony
  • Rust

Извиняюсь, если разочаровал.

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

в d есть полная поддержка gtk

Он неудобный и не кросспатформенный.

так же есть dlangui

Убогая и глючная васянская поделка, небось.

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

Если любишь странное tkd есть, тоже полная реализация, вообще d очень легко любые либы c использует, не как в расте танцы с бубном

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

Для таких вещей это естественная среда обитания

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

Я вот тоже с плюсов слажу на раст. Хотя по-прежнему пишу на C++, ибо Qt.

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

uds добавили еще в прошлом году, обнови кеш.

А для остального есть хорошие либы

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

Не все пишут вебсервера. Мне 300 лет не сдался сетевой фреймворв в std.

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

Серьёзно?

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

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

Это для обычных либ правдиво. А неблокирующая сетевая либа - вещь ключевая.

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

Хорошие сетевые неблокирующие абстракции - язык живет. Плохие - нет языка

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

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

Я лично писал биндинги к либам. Так что давайте конкретные примеры.

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

Прочёл, однако ничего нестабильного не нашёл.
Можешь указать на что-то конкретное?

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