LINUX.ORG.RU

Rust 1.19

 


3

8

Команда Rust рада объявить о последней версии Rust, 1.19.0. Rust это системный язык программирования, сфокусированный на безопасности, скорости и конкурентном выполнении.

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

$ rustup update stable

В противном случае, вы можете получить rustup с соответствующей страницы на нашем вебсайте и проверить детальные примечания к выпуску для 1.19.0 на Github.

Что нового в 1.19.0 stable

Rust 1.19.0 получил некоторые долгожданные возможности, но для начала примечание для наших пользователей Windows. На Windows Rust полагается на link.exe для линковки, который вы можете получить из “Microsoft Visual C++ Build Tools.” С последним выпуском Visual Studio 2017, структура каталогов для этих инструментов изменилась. Таким образом, чтобы использовать Rust, вы должны придерживаться инструментов 2015 или использовать обходной путь (такой как запуск vcvars.bat). В 1.19.0 rustc теперь знает, как найти инструменты 2017, и они работают без использования обходных путей.

А теперь к новым возможностям! Rust 1.19.0 это первый выпуск, который поддерживает объединения (unions):

union MyUnion {
    f1: u32,
    f2: f32,
}

Объединения это вид перечислений (enums), но в отличие от последних они «непомечены» («untagged»). Перечисления имеют «пометку», которая хранит информацию, какой вариант является правильным в рантайме; объединения игнорируют эту пометку.

Так как мы можем интерпретировать данные, хранящиеся в объединении, используя неправильный вариант, и Rust не может проверить это для нас, это означает, что чтение или запись поля объединения является unsafe:

let u = MyUnion { f1: 1 };

unsafe { u.f1 = 5 };

let value = unsafe { u.f1 };

Сопоставление с образцом также работает:

fn f(u: MyUnion) {
    unsafe {
        match u {
            MyUnion { f1: 10 } => { println!("ten"); }
            MyUnion { f2 } => { println!("{}", f2); }
        }
    }
}

Когда полезны объединения? Одним из основных случаев использования является интероперабельность с Си. C API могут использовать объединения, и во многих областях часто это делают, и с появлением объединений в Rust написание оберток для API подобных библиотек становится значительно проще. Дополнительно, из этого же RFC:

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

Эту возможность уже давно ждали, и еще больше улучшений на подходе. Сейчас объединения могут только содержать Copy типы и не могут реализовывать Drop. Мы ожидаем снятия этих ограничений в будущем.

Также циклы loop теперь имеют возможность возвращать значение при выходе с break:

// old code
let x;

loop {
    x = 7;
    break;
}

// new code
let x = loop { break 7; };

Rust традиционно позиционируется как «язык, ориентированный на выражения», в котором большинство вещей являются выражениями, вычисляющимися в значения, а не директивами. Раньше loop странно выделялся, так как был директивой.

Что насчет других форм циклов? Здесь еще не всё ясно. Посмотрите этот RFC для ознакомления с некоторыми дискуссиями вокруг открытых вопросов.

Замыкания, которые не захватывают окружение, теперь могут быть приведены к указателю на функцию:

let f: fn(i32) -> i32 = |x| x + 1;


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

Стабилизация стандартной библиотеки

Наибольшей новой библиотечной возможностью являются макросы eprint! и eprintln!. Они работают так же, как и print! и println!, но пишут в стандартный поток ошибок, а не в стандартный поток вывода.

Другие нововведения:

.

И некоторые недавно стабилизированные API:

Смотрите детальные примечания к выпуску для получения более подробной информации.

Cargo

Cargo в основном получил небольшие, но значимые улучшения в данном выпуске. Так, Cargo больше не проверяет локальный рабочий каталог для индекса crates.io. Это должно обеспечить меньший размер файла для реестра и улучшить время клонирования, особенно на машинах Windows.

Другие улучшения:

Смотрите детальные примечания к выпуску для получения более подробной информации.

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

★★★★★

Проверено: Shaman007 ()
Последнее исправление: Virtuos86 (всего исправлений: 3)

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

продукт уровня Servo

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

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

Я не очень понимаю, в чем проблема наравне с apt/yum использовать ещё и cargo/gem/whatever? Перфекционизм или на больше одного ПМ нейронных связей не хватает?

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

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

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

Не вижу никакого продукта, извини.

Сам объём напиливания впечатляет, достаточно еженедельный блог почитать

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

Очевидно, что его размер монструозный, что там мегатонны кода и логично, что он очень сложный. Что в итоге получиться, пока не ясно. Но мне очевидно, что два чувака из KHTML не осилили бы такой объём

AntonyRF ★★★★
()

cargo разве не аналог cpan'a для Rust?

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

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

Звучит как приговор.

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

То есть ты не видишь разницы между движком для современного веба и движком для древнего HTML 3.2? И судя по тому, что я прочитал его более 2 человек писало (еще и полностью переписывали для того, чтобы добавить поддержку скриптов и CSS). И написан он более 20 лет назад, как я и сказал, когда еще было более-менее реально за нормальное время написать движок с 0.

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

Я не очень понимаю, в чем проблема наравне с apt/yum использовать ещё и cargo/gem/whatever?

Что случится, если я установлю программу A, зависящую от библиотеки B через пакетник 1? Пакетник 1 вытащит из репозитория библиотеку B и программу A и установит. Теперь пакетник 1 знает, что библиотека B установлена и программы для установки программ A1, A2, A3, зависящих от библиотеки B её не требуется устанавливать в n-ый раз. А теперь я хочу установить программу A4, зависящую от библиотеки B через пакетник 2. Пакетник 2 не знает о существовании на диске ни пакетника 1, ни библиотеки B. И он скачает и установит её ещё раз — это в лучшем случае, в худшем случится конфликт файлов (это если он захочет установить B туда же куда установил пакетник 1) и привет.

В конечном счёте в системе окажутся дубликаты практически всех библиотек. Продублированы они будут n раз, где n = количеству пакетников в системе.

Конкретно cargo плох тем, что всё линкует статически, а значит куски кода (явно пересекающиеся) библиотеки B окажутся зашиты в программах A1, A2, ..., An. И если язык с таким инструментарием станет основным в линуксе, то это будет линуксокапец.

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

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

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

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

Конкретно cargo плох тем, что всё линкует статически, а значит куски кода (явно пересекающиеся) библиотеки B окажутся зашиты в программах A1, A2, ..., An. И если язык с таким инструментарием станет основным в линуксе, то это будет линуксокапец.

Cargo может линковать динамические бибилиотеки. Просто динамические бибилиотеки - это unsafe.

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

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

А сейчас употребление смузи и маффинов, латте и чизкейка самым драматическим образом уменьшают работоспособность программистов?

То есть ты не видишь разницы между движком для современного веба и движком для древнего HTML 3.2?

Принципиальной разницы нет.

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

Просто динамические бибилиотеки - это unsafe.

С каких это пор prefer-dynamic требует unsafe?

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

если язык с таким инструментарием станет основным в линуксе, то это будет линуксокапец

Тут можно не беспокоиться. Упорина на планете не хватит, чтобы массово стали на русте писать.

bread
()

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

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

Звучит как приговор.

Это настолько звучит как приговор, что разработчики выкинули Си\Си++ и начали пилить свой ЯП, чтобы совладать с задачей

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

Что случится, если я установлю программу A, зависящую от библиотеки B через пакетник 1?

Вы несёте какую-то дичь!

Cargo - это вообще не пакетный менеджер по сравнению с apt-get\yum\zypper. Он может установить библиотеки (исходный код) ТОЛЬКО написанные на rust и программы он может установить, которые ТОЛЬКО дополняют rust\cargo. Всё что Вы написали какой-то дикий бред!

Например: Чтобы использовать OpenSSL вам всё равно нужно установить libssl-dev через apt-get\yum\zypper и Вам всё равно нужно прописать в зависимостях проекта openssl, чтобы cargo скачал исходный код библиотеки которая содержит биндинги к libssl-dev. Ни какого дублирования ни какой херни не будет

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

Ты не понял о чем он говорил. Он про то что если у тебя есть две программы на расте и они обе зависят от либы на расте например clap. Одну из них ты поставил через apt и она постпвила в систему libclap. А вторую через карго и она поставила libclap в .cargo. Итого у тебя в системе две либы.

Хотя я думаю эта проблема решается через --extern

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

Все с тобой ясно.

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

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

Ты не понял о чем он говорил.

Посмотрел последние 3 коммента, показалось, что он говорил о другом, ну да ладно(((

А вторую через карго и она поставила libclap в .cargo. Итого у тебя в системе две либы.

Ну хз, у меня такой проблемы не было. А как разработчики ПО для новых дистрибутивов выкатывают новую версию софта, которой нужны новые версии либы, но разработку ведут на старом дистрибутив?

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

О да умник, конечно же нет. Только жирней стал на 10*10^3 %

О да, появилась поддержка SVG. Очень актуально. Поддержка MathML (как же мы раньше без этого жили?). Не будем забывать про анальные Hello и Pocket. И да, как же без читалки pdf в браузере? При том, при всем - на тормозном скрипте интерфейс умирает. Но это решать неинтересно, мы лучше web-инспектор запилим.

Могу продолжить ряд, хотя мысль должна быть ясна даже распоследнему болвану.

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

Ты идиот? Сравни что нужно было реализовать в движке 1999 года с тем, что нужно в движке 2017 года. И учти, что тогда многие вещи можно было сделать тривиально, так как страницы были простые. GPU-рендерингом, многопоточностью, JIT компиляцией скриптов и еще уймой всякой херни, которую должен уметь современный браузер, чтобы нормально открывать современные монструозные страницы, написанные с использованием современным монструозных стандартов (в лучшем случае, в реальном мире там еще куча браузеро-специфичных костылей) и при этом не быть дырявым насквозь.

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

бла-бла-бла...

Угу, например у khtml интерфейс никогда не вставал раком.

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

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

Конфликт файлов будет только, если ты поставишь две одинаковых библиотеки, которые пересекаются по файлам. Да и это маловероятная ситуация - пакетники ЯП обычно ставят библиотеки в отдельные директории, не пересекающиеся с системными, никаких конфликтов у тебя не будет.

Я не знаю, чего удивляться. Такому подходу не один год, никто не умер и это работает. Невозможно в репах дебиана держать _ВСЕ_ либы условного раста или руби или перла. Ну вот невозможно, не будет так никогда. Потому что это лишняя работа для разработчиков либ, бюрократия дистрибутива и все на это забьют.

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

Такому подходу не один год, никто не умер и это работает

Основная масса софта работает не через эту жесть, потому, что основная масса софта написана на C/C++.

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

Вот именно эту проблему и нужно рассматривать — высокий порог вхождения в «мейнтейнеры». И она решена — AUR в арче и оверлеи в генте.

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

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

Опакеть десятки тысяч пакетов и будет всё хорошо

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

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

CUDA — на помойку, как и всё, что от неё зависит. Qt — на помойку, как и всё, что от него зависит. LLVM — ну ты понял куда, как и всё что от него зависит.

Собранный привет миру на rust с llvm с отладочными символами, без оптимизаций и так далее не весит даже половину мегабайта.

тряска очень вредна

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

И на 16 GB, которые у меня под корень выделены явно не влезет виста с IDE-шкой, брузаком и прочими мелочами для уюта.

16 Гб даже по меркам 2007 года - очень мало. Но мракобесы привыкли к тому что система влазит на дискету, и больше ничего не замечают

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

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

А тебе уже говорили что там ещё и свой алокатор имеется?

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

GNU/Linux

Какая из? Вон, в некоторых даже уязвимости править не спешат, не говоря уже про средства разработчика

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

Могу продолжить ряд, хотя мысль должна быть ясна даже распоследнему болвану.

Ну и ещё забыли о JS см ES6, CSSv3 и его дополнения и о HTML5 с его Canvas и 3d. На каждое из этих слов нужны мегабайты кода на Си\Си++\Rust в зависимости от движка. Чтобы это работало и работало быстро и слажено и параллельно нужно много-много человеко-лет работы, если Вы в этом сомневаетесь, то скорее всего ни чего сложнее калькулятора не программировали.

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

Итого есть везде, кроме винды. Где тоже есть, но немножко не так, как хочется некоторым. Ну ок.

Расскажи это не мне, а тому кто не осилил qt под виндой

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

И выкачивать гигабайт (ну ладно, не гигабайт — 900 мегабайт) зависимостей в папку с проектом.

И какой же это проект? Расскажи. И потом, ты сразу над сотней проектов работаешь?

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

Так добавь сам. Какие проблемы?

Какой смысл добавлять самому, если всё уже можно сделать одной командой?

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

А пользователь будет страдать

Пользователь это кто - тот кто решил собрать проект или тот кто поставит бинарник? Если первое, то ты садист? Если второе, то это ложь.

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

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

В любом. Просто скачай и распакуй

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

Рудименты ещё не проходил, да?

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

HTML5 с его Canvas и 3d. На каждое из этих слов нужны мегабайты кода на Си\Си++\Rust

На rust пока только парсер mp4-файлов - строчек 150 на С. (Да, rust пока себя никак не проявил, хе-хе-хе). Насчет остального (хотя реализация этого - мегабайты, а не сотни мегабайт), да это важно, но прежде чем мозилловцам было бросаться как льву на свежее дерьмо на эти красивые словечки, нужно было разнести код обработки пользовательского интерфейса и js.

anonymous
()

Почему никто не обсуждает идеология языка? Дали на самом деле крутые вещи: строгую и статическую типизацию, функциональное программирование и при этом рантайм на уровне С. А мартышки обсуждают настолько поверхностные вещи как угловые скобки и систему сборки. Есть здесь проффесионалы, или только форумные троли? Какая разница что на нем написанно и кто его юзает, если инструмент действительно уникальный и крутой.

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

KHTML
Был представлен в 2000 году

А просвети сенсей, сколько тогда сложных интернетов было?

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

В любом. Просто скачай и распакуй

Т.е. ни в каком, стеснительный ты наш.

Рудименты ещё не проходил, да?

Лапочка такой смешной...

anonymous
()

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

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

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

И да, парсинг css - это далеко не движок.

По твоему движок появится сам, сразу?

Парсинг css - в последнюю очередь.

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

тем что бинарь будет не сто килобайт а мегабайт?

Для этого ещё надо постараться

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