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)

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

Я к тому, что D недостаточно инновационный чтобы повсеместно заменить c++ или джаву. Прямо как в истории про руби и пхп

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

Прямо как в истории про руби и пхп

А разве Ruby создавали как замену PHP?

Я вот, например, стал пользоваться Ruby еще до появления RoR, как-то тогда конкуренции между Ruby и PHP не было. А язык был востребован для скриптовых задач.

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

Да, но нет. Т.к. это опенсурс, то всегда найдется кучка RMSов и Линусов на развитие аля just for fun.

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

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

А язык был востребован для скриптовых задач.

У него одна проблема. Свое менеджер пакетов.

Они из-за заточки под винь создали и используют его.

Отличный пример для rust'оманов.

Где окажитесь, если будете из-за заточки под винь использовать свой менеджер пакетов.

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

Свое менеджер пакетов.

Да как же вы уже надоели со своим бредом. У большинства современных языков есть свой ПМ. И винда тут не при чём. Вылезайте уже из своего манямирка С/С++.

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

Емнип, в треде про прошлый релиз анонимусы и многие другие, в том числе и вы, доказывали, что свои ПМ это зло, и нужно использовать системные (dpkg, yum, pacman etc.)

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

Я более чем уверен, что это один и тот же пациент.

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

И какая проблема у RubyGems?

Что большинства из gems нет в репозитариях дистрибутивов а значит никто не будет в дистрибутив пихать пакеты использующие то, чего нет.

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

Поехавший, просто поехавший. Даже серьёзные ребята (перловики) решили, что cpanm - рулит.

И где теперь perl. На обочине. Только легаси. Молодцы. Чо?

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

Емнип, в треде про прошлый релиз анонимусы и многие другие, в том числе и вы, доказывали, что свои ПМ это зло, и нужно использовать системные (dpkg, yum, pacman etc.)

Двайте так: если вы какую-то фразу или утверждение приписываете мне, то берете на себя труд подтвердить это соответствующей цитатой.

Где я что-то говорил про «свои ПМ — это зло»?

Пруф или не было.

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

Что большинства из gems нет в репозитариях дистрибутивов а значит никто не будет в дистрибутив пихать пакеты использующие то, чего нет.

Похоже, вы о чем-то своем, очень-очень личном.

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

Похоже, вы о чем-то своем, очень-очень личном.

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

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

Двайте так: если вы какую-то фразу или утверждение приписываете мне, то берете на себя труд подтвердить это соответствующей цитатой.

Где я что-то говорил про «свои ПМ — это зло»?

Там 24 страницы. Давайте так, оплатите мне время, которое я потрачу на поиск конкретных пруфов. Далее, я сделал удобную оговорку «если мне не изменяет память». Вполне возможно, что я под одну гребёнку гребу всех критиканов в данном случае, и вы обсуждали что-то другое, ибо тред разбился на несколько веток. В таком случае, я всего лишь ошибся. Видимо, того анонимуса, который взъелся тогда на Cargo, сегодня здесь нет.

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

Давайте так, оплатите мне время, которое я потрачу на поиск конкретных пруфов.

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

Далее, я сделал удобную оговорку «если мне не изменяет память». Вполне возможно, что я под одну гребёнку гребу всех критиканов в данном случае, и вы обсуждали что-то другое, ибо тред разбился на несколько веток. В таком случае, я всего лишь ошибся.

Если я напишу, что если мне не изменяет память и в какой-то теме некто с ником похожим на Virtuos86 сравнивал программирование на C++ со своим первым гомосексуальным опытом, а потом скажу «я всего лишь ошибся», то это для вас будет нормальным способом ведения дискуссии? Ну а что, память подвела, лень копаться по старым темам...

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

Если не ошибаюсь, то автор дока раста сам пришёл с руби. Как и многие другие.

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

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

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

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

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

Там 24 страницы. Давайте так, оплатите мне время, которое я потрачу на поиск конкретных пруфов.

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

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

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

Бремя доказательств лежит на том, кто утверждение сделал.

Если вы говорите, что я, среди прочих, доказывал вредность собственных ПМ для ЯП, то это вам нужно подтвердить свои слова.

И вам для этого нужна будет всего лишь одна цитата.

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

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

попутно оскорбляя оппонента

Это лор, чувак. Звезлы отрастил и не закалился? Разбабились, Луговского на вас нет...

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

Всё в ваших руках. Биндинги пишутся за вечер.

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

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

И перл. И RoR. И Ada использовали.

Всё еще есть ненулевая вероятность, что раст останется не обочине и мейнстримом не станет.

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

Мейнстримом? Ахахах! Нет, успех уровня хачкеля это будпт круто, чуваки.

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

И перл. И RoR. И Ada использовали.

Ты только что привёл 3 очень популярных технологии, которыми пользуются и сегодня. Если Rust дорастёт до уровня RoR, это будет безумный успех.

Всё еще есть ненулевая вероятность, что раст останется не обочине и мейнстримом не станет.

Есть, конечно. Но предпосылок к этому пока не видно.

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

D, который 17 лет развивается just for fun, без поддержки больших корпораций.

А чем D лучше С++? Он не даёт ни чего нового, ни тебе безопасности, ни фишек типа владения как в Rust'e. Да даже ничего типа STL нет. Это мёртворождённый проект, а на Rust есть пока надежды.

Тут очень хочется спросить: а вы там случайно не в числе топовых разработчиков числитесь?

У нас нет такого разделения.

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

Он не даёт ни чего нового

Вы его с кем-то путаете.

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

А чем D лучше С++? Он не даёт ни чего нового, ни тебе безопасности, ни фишек типа владения как в Rust'e. Да даже ничего типа STL нет.

Афигеть, дайте два! Да вы прям жгете напалмом.

D и C++ находятся в разных категориях, т.к. D — это язык с GC.

По поводу того, что дает D, так это и модульность, и быстрая компиляция (по крайней мере в DMD-варианте), и наличие иммутабельности (типа C++ных const, но на стероидах), и рефлексия времени компиляции, а в сочетании с compile-time function evaluation и текстовыми mixin-ами эта штука посильнее иных макропроцессоров будет, design by contract (один из немногих после Eiffel-я, кто это дает из коробки). Плюс шаблоны, которые всегда были даже более продвинутыми, чем в C++ (емнип, variadic templates сперва именно в D появились). Тот же static if сперва появился в D, только затем, спустя десять лет, его скомуниздили в C++17.

С безопасностью там более чем нормально.

А уж по поводу STL... За это вам отдельное спасибо, поржал: std.algorithm, std.ranges, std.array и т.д.

Это мёртворождённый проект

Он-то, может и мертворожденный, но совсем не по тем причинам, которые вы озвучиваете.

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

Он-то, может и мертворожденный, но совсем не по тем причинам, которые вы озвучиваете

Да по этим. Раз его сделали GC - значит конкурент Java, C#. А в последних всё вами перечисленное, в той или иной степени, наличествует

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

Да по этим. Раз его сделали GC

Позволю себе напомнить список причин, озвученных тов.AntonyRF:

А чем D лучше С++? Он не даёт ни чего нового, ни тебе безопасности, ни фишек типа владения как в Rust'e. Да даже ничего типа STL нет. Это мёртворождённый проект, а на Rust есть пока надежды.

Тут нет упоминания GC и близко.

значит конкурент Java, C#. А в последних всё вами перечисленное, в той или иной степени, наличествует

Ага, особенно в Java :) Рефлексия времени компиляции, текстовые mixin-ы, design by contract, иммутабельность. Прям вагон. Та еще и толстенный JRE в придачу.

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

Рефлексия времени компиляции, текстовые mixin-ы, design by contract, иммутабельность.

Как видишь индустрии не интересны эти шипастые пограмистские дилды. То же будет и с рустом.

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

Ага, особенно в Java :)

таки иммутабельность «а-ля const в C» там есть, контракты более-менее прикручиваются изолентой со сторонними либами.

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

Он бредит. Нет в Java иммутабельности и не будет. Там есть только иммутабельные ссылки (final), что значит, что нельзя поменять саму ссылку, но спокойно можно менять сам объект, на который такая ссылка ссылается. Так что там даже примитивной иммутабельности с стиле C++ нет.

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

Там есть только иммутабельные ссылки (final), что значит, что нельзя поменять саму ссылку, но спокойно можно менять сам объект, на который такая ссылка ссылается.

О том и речь. Но пускай arkhnchul докажет свои слова кодом.

eao197 ★★★★★
()
Ответ на: комментарий от eao197
final class SomeClass {
    private final int foo;
    
    public SomeClass(int foo){
        this.foo = foo;
    }
    
    public int getFoo(){
        return foo;
    }
}

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

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

какие-то части, говорят. А еще расширения можно на расте.

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

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

Scala, например, кому-то нужна и особого дробления сообщества не замечено.

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

Си как-то особо сильно не отличается в этом плане, по крайней мере в современных стандартах. Да, никто не помешает кастануть type const * -> type * или даже вообще в совсем другой тип, но конкретно такой каст - это UB, Си тем и отличается, что дает гранатомет без предохранителя любой макаке.

В Java же нет даже такого, там есть только аналог type * const. Единственный способ достичь иммутабельности - спроектировать иммутабельный интерфейс. Причем не будет никакого контроля от компилятора, что данные фактически не меняются внутри из-за ошибки. Нельзя просто модификатором запретить изменения внутренностей.

Ну хотя бы не как гоферы.

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

я хоть слово сказал о C++, батенька?

Т.е. это вы намеренно в разговор о том, чем D отличается от Java, C++ и C#, приплели plain old C? Да вы еще умнее, чем казались!

Ну давайте посмотрим на const из чистого С:

#include <time.h>

int main() {
	struct tm t;
	t.tm_mday = 3;

	struct tm * modifyable = &t;
	modifyable->tm_mday += 1;

	const struct tm * readonly = &t;
	readonly->tm_mday += 1; // Oops...
}
Строка readonly->tm_mday += 1 просто не скомпилируется. И это свойство константности распространяется на любой тип, а не только для вашей пародии на "(почти) иммутабельны".

Только вот в C и C++ const T* — это всего лишь read-only view на данные. Сами данные могут быть мутабельными. Что, временами, может приводить к ошибкам в коде. А вот в D immutable T означает именно что иммутабельные данные, которые не могут поменять свое значение. И это так для любого T.

Ну и что, вы по-прежнему уверены, что иммутабельность данных в Java есть?

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

иммутабельность данных

Нужна только косоруким кодеркам, рандомно жмущим на клавиши левой пяткой.

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

Гофер детектед. Уже везде успел расставить комменты?

// Caller must not modify the map.

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