Мы рады представить новую версию Rust 1.11. Rust — это системный язык программирования, нацеленный на безопасную работу с памятью, скорость и параллельное выполнение кода.
Как обычно, вы можете установить Rust 1.11 с соответствующей страницы официального сайта, а также ознакомиться с подробным списком изменений в этой версии на GitHub. В этот релиз вошло 1109 патчей.
Что вошло в стабильную версию 1.11
В 1.11 мы много работали над внутренностями компилятора, которые ещё не стабильны. Мы рады сообщить, что MIR скоро станет транслятором по умолчанию и мы делаем первые шаги в направлении инкрементальной компиляции. В выпуске 1.11 мы заложили фундамент для этой работы.
Что касается видимых пользователям изменений, в последнем выпуске мы рассказывали о новом типе контейнера — cdylib.
Существующий формат динамических библиотекdylibотныне используется только для динамических библиотек, используемых в проектах на Rust, аcdylibбудет использоваться при компиляции кода на Rust для встраивания в другие языки. В выпуске 1.10cdylibподдерживается компилятором, но пока не поддерживается Cargo. Этот формат был определён в RFC 1510.
Итак, в Rust 1.11 Cargo поддерживает cdylib'ы! Добавив такой код в Cargo.toml
crate-type = ["cdylib"]вы получите такой контейнер.
В стандартной библиотеке мы изменили хэширующую функцию по умолчанию с SipHash 2-4 на SipHash 1-3. Мы давно думали над этим, начиная с исходного решения использовать 2-4:
мы предложили SipHash-2-4 в качестве (сильной) PRF/MAC, и на данный момент не было найдено никаких атак на него, хотя многие компетентные люди пытались его сломать. Однако, может хватить и меньшего числа раундов, и я бы очень удивился, если бы SipHash-1-3 был бы уязвим при использовании в хэш-таблицах.
Замечания
Подробнее о изменениях в языке в целом можно прочитать в замечаниях к выпуску.
Стабилизация библиотек
BinaryHeap,BTreeMap, иBTreeSetполучили методappend. Также, добавленsplit_offдляBTreeMapиBTreeSet::split_off.- Методы
to_degreesиto_radiansбыли реализованы дляf32иf64вlibstdи раньше, а теперь они доступны и вlibcore. - У
Iteratorдва новых метода:sumиproduct. CellиRefCellполучилиget_mut.assert_eq!принимает пользовательское сообщение об ошибке, какassert!.- Главный поток теперь называется "main" вместо "<main>".
Подробнее смотрите замечания к выпуску.
Возможности Cargo
- В Cargo добавлена поддержка цвета в консоли Windows, и теперь вы можете задавать цвета для stderr, а не только для stdout.
- Скрипты сборки теперь могут выдавать предупреждения.
- Как мы говорили выше, добавлена поддержка контейнеров типа cdylib.
- Cargo теперь не даёт публиковать контейнеры, если у вас есть несохранённые изменения в рабочей копии.
Подробнее смотрите замечания к выпуску.
Разработчики версии 1.11
В выпуске версии 1.11 участвовало 126 человек. Большое вам спасибо!
- Aaklo Xu
- Aaronepower
- Aleksey Kladov
- Alexander Polyakov
- Alexander Stocko
- Alex Burka
- Alex Crichton
- Alex Ozdemir
- Alfie John
- Amanieu d'Antras
- Andrea Canciani
- Andrew Brinker
- Andrew Paseltiner
- Andrey Tonkih
- Andy Russell
- Ariel Ben-Yehuda
- bors
- Brian Anderson
- Carlo Teubner
- Carol (Nichols || Goulding)
- CensoredUsername
- cgswords
- cheercroaker
- Chris Krycho
- Chris Tomlinson
- Corey Farwell
- Cristian Oliveira
- Daan Sprenkels
- Daniel Firth
- diwic
- Eduard Burtescu
- Eduard-Mihai Burtescu
- Emilio Cobos Alvarez
- Erick Tryzelaar
- Esteban Kuber
- Fabian Vogt
- Felix S. Klock II
- flo-l
- Florian Berger
- Frank McSherry
- Georg Brandl
- ggomez
- Gleb Kozyrev
- Guillaume Gomez
- Hendrik Sollich
- Horace Abenga
- Huon Wilson
- Ivan Shapovalov
- Jack O'Connor
- Jacob Clark
- Jake Goulding
- Jakob Demler
- James Alan Preiss
- James Lucas
- James Miller
- Jamey Sharp
- Jeffrey Seyfried
- Joachim Viide
- John Ericson
- Jonas Schievink
- Jonathan L
- Jonathan Price
- Jonathan Turner
- Joseph Dunne
- Josh Stone
- Jupp Muller
- Kamal Marhubi
- kennytm
- Le?o Testard
- Liigo Zhuang
- Loic Damien
- Luqman Aden
- Manish Goregaokar
- Mark Cote
- marudor
- Masood Malekghassemi
- Mathieu De Coster
- Matt Kraai
- Matyas Mustoha
- M Farkas-Dyck
- Michael Necio
- Michael Rosenberg
- Michael Woerister
- Mike Hommey
- Mitsunori Komatsu
- Morten H. Solvang
- Ms2ger
- Nathan Moos
- Nick Cameron
- Nick Hamann
- Nikhil Shagrithaya
- Niko Matsakis
- Oliver Middleton
- Oliver Schneider
- Paul Jarrett
- Pavel Pravosud
- Peter Atashian
- Peter Landoll
- petevine
- Reeze Xia
- Scott A Carr
- Sean McArthur
- Sebastian Thiel
- Seo Sanghyeon
- Simonas Kazlauskas
- Srinivas Reddy Thatiparthy
- Stefan Schindler
- Steve Klabnik
- Steven Allen
- Steven Burns
- Tamir Bahar
- Tatsuya Kawano
- Ted Mielczarek
- Tim Neumann
- Tobias Bucher
- Tshepang Lekhonkhobe
- Ty Coghlan
- Ulrik Sverdrup
- Vadim Petrochenkov
- Vincent Esche
- Wangshan Lu
- Will Crichton
- Without Boats
- Wojciech Nawrocki
- Zack M. Davis
- ???
Комментарии (29)
ozkriff
19.08.2016 17:18+4Еее! Все по расписанию, круто! :-D
Я тут с месяц назад опять вернулся к относительно активной работе над своей игровой поделкой на ржавчине — https://github.com/ozkriff/zoc.
snuk182
20.08.2016 21:10+2Cпасибо, я как раз позавчера из нее утянул способ подружить rusttype и glium. Viva la Open Source!
ozkriff
21.08.2016 01:35+1Рад быть полезным)
А вообще, там же в самом репозитории rusttype пример использования динамического текстурного атласа есть: https://github.com/dylanede/rusttype/blob/7d0664/examples/gpu_cache.rs
Мне этот атлас только не понравился тем, что очень сильно уж динамический — фактически, требует после любого малюсенького изменения заново всю геометрию перегенерировать.
snuk182
21.08.2016 13:41С другой стороны, его можно обернуть в более высокоуровневый кеш или LRU — и на том спасибо, как говорится.
Кстати, как вам gfx, стоит внимания в текущем виде?ozkriff
21.08.2016 16:26+2Кстати, как вам gfx, стоит внимания в текущем виде?
Ну я три недели назад наконец-то переписал свою штуку с древних велосипедов на GFX и пока вполне доволен) Колебался между glium и GFX — оба, в принципе, неплохи, но у glium какие-то непонятные планы на будущее и он жестко завязан на GL2/3.
У GFX разве что хуже с документацией для новичков — чего-то актуального и близкого к http://tomaka.github.io/glium/book пока нет. Зато есть примеры, документация для основных типажей/структур и всегда можно спросить чего-то в https://gitter.im/ruRust/gamedev — меня устраивает)
snuk182
21.08.2016 17:40Там не то, что хуже, ее просто нет. Заглянуть в examples особо не помогает — там куча декларативного кода на макросах, который человеку, мало понимающему в графических технологиях, не говорит вообще ничего. Особенно забавно наблюдать периодически всплывающие тикеты с просьбами пополнить документацию и туториалы, и удивленные ответы там от разработчиков — мол, а что, вам что-то непонятно?
ozkriff
21.08.2016 20:26+1Я под "новичками" подразумевал "не знакомый с этой библиотекой" скорее. Все-таки если более-менее знаешь ржавчину и имеешь кое-какой опыт с 3д графикой, то, кмк, по вышеописанным источникам знаний разобраться вполне реально.
Сомневаюсь, что GFX на текущем этапе развития ориентируется на полных новичков в 3д. Ну и библиотека все-таки еще не до конца устоялась — тоже аргумент против концентрации усилий на доках.
Вряд ликто-то спорит, что обширная документация не помешала бы, просто ее написание тоже трубет пропорционально обширных ресурсов, которых у основных авторов библиотеки сейчас нет :( .
kvark
22.08.2016 17:01+3удивленные ответы там от разработчиков — мол, а что, вам что-то непонятно
Хех, а можно подробнее? :)
Тут вариантов несколько. Скажем, если человек возмущается, мол, что нету доков вообще, то естественно никто не бросается описывать ВСЁ. Мы уточняем, где конкретно непонятно, чтобы с минимальными усилиями добиться максимального эффекта — хотя бы документацию прямо в коде подправить и уточнить.
Вы ж не подумайте, что мы ожидаем от всех, что наш API будет очевиден ;) Как закончим Vulkan и Metal, устаканимся с моделью API, там будет рационально и документацией заняться. Любая помощь приветствуется!
snuk182
22.08.2016 17:25+1Вот, к примеру. Или вот. Очень отрадно, что вы даже при такой постановке вопроса пытаетесь его решить.
Лично мне не хватает туториала для чайников, как в glium. Потому очень помог код ozkriff (и его подсказка насчет vange, сам бы я его не нашел), поскольку в нем более понятно, откуда что берется и (что немаловажно) как его подробить на отдельные части.
snuk182
22.08.2016 17:31+2С удовольствием бы помог с подобным туториалом, если бы сам понимал графику дальше OpenGLных хеллоуворлдов (хоть и довольно продвинулся в их изучении) :(
splav_asv
21.08.2016 22:44У glium вроде как раз понятные планы — поддержка только GL2/3, GL3 как основная. Для более продвинутых случаев позиционируется vulkano — Vulkan соответственно. Автор, вроде как, устал биться о стену багов в реализациях GL4 и советует его вообще не использовать.
ozkriff
22.08.2016 14:16+1В этом смысле, конечно, планы понятные.
Но вот будущее библиотеки мне видится туманным. Разве много кто на ней будет основывать новые проекты, если в долгосрочной перспективе gl2/3 будет только устаревать и все? С glium на vulkano (или на что еще) проект безболезненно не переведешь. Томака сейчас уже возится с glium постольку-поскольку, ему гораздо интереснее разрабатывать vulkano, а больше поддержкой особо никто не занимается.
snuk182
22.08.2016 19:35+1Все же поддержка Vulkan пока оставляет желать лучшего, один только эпик тред с концентрированным пожеланием счастья NVidia чего стоит. На мобильных девайсах вестимо все еще печальней, учитывая качество поддержки вендорами их поделок.
ozkriff
23.08.2016 10:26Это да, я для своей поделки сам пока в первую очередь GL2/GLES2 бекенда придерживаюсь пока что. Но все равно намного приятнее знать, что проект, в который ты порядочно сил вкладываешь и не планируешь забрасывать через месяц-другой, меньше потом придется переписывать.
ozkriff
23.08.2016 10:29+2Заодно уж напишу тут, что вчера вечером выкатил ежемесячник по проекту:
https://users.rust-lang.org/t/this-month-in-zone-of-control/6993/1
tgz
19.08.2016 22:09А что хорошего в MIR? Расскажите…
splav_asv
19.08.2016 22:40+5MIR — промежуточное представление между HIR (~AST) и LLVM IR.
Если кратко:
Со стороны пользователя
1) Является часть работы по внедрению инкрементальной компиляции — проще в обращении.
2) Позволяет делать часть специфичных оптимизаций на этом этапе, до оптимизаций LLVM
3) Более точный контроль типов и заимствований, позволит более точно контролировать заимствования, чуть ослабить требования (есть несколько очевидных мест, где контроль излишне жесткий из-за особенностей текущей реализации).
4) Позволило провести ряд долгожданных улучшений, например выкинуть скрытый бит drop из структур.
Со стороны компилятора
4) Некоторое упрощение внутренней архитектуры, уменьшение связности.
kvark
Не вводите народ в заблуждение! MIR в стабильном Rust 1.11 всё так же выключен по умолчанию, а включён он в Rust 1.12 beta, вышедшей в тот же день.
В целом релиз получился достаточно скромный, что говорит только об одном — заканчивайте уже ждать чуда и начинайте писать на языке — он уже давно стабилизоровался и годен к использованию.
mkpankov
Поправил, чтобы было понятнее, что имеется ввиду.
Laney1
вообще это не совсем так. В последнее время в rust особо ничего не меняли как раз из-за того что запиливали MIR. Пару дней назад в ночные сборки добавили такую важную фичу как abstract return types, не удивлюсь если это приведет к большим изменениям в стандартной библиотеке.
Плюс в rust есть и другие, критичные для многих недостатки. Например, до сих пор не стабилизированы simd-интринсики и/или ассемблерные вставки, хотя работа вроде ведется.
kvark
breaking changes? Сомневаюсь. Если они что-то и будут менять в стабильных интерфейсах стандартной библиотеки, то хорошенько пройдутся crater заведомо, чтобы точно никого не сломать. Так что бояться этого нет смысла.
Это достаточно нишевые фичи, доступные в ночных сборках на крайняк. Так что "давно стабилизоровался и годен к использованию" вполне истинно для большинства прикладных задач.
Laney1
намного менее нишевые, чем может показаться. Например, вы желаете зашифровать что-нибудь стандартным алгоритмом, или посчитать хэш. Открываете crates.io и ищете нужный крейт. Находите кучу вариантов, из которых одна часть требует ночную сборку, что далеко не всегда вариант (в продакшн-коде, я бы сказал, вообще никогда не вариант), другая работает в пару раз медленнее того что вы ожидали, а третья требует сишные библиотеки (тогда вообще непонятно, какие у rust преимущества перед go и python: критичные участки кода написаны на Си, а для некритичных намного удобнее пользоваться языками со сборкой мусора)
kvark
Проблема кажется слегка надуманной:
Для вас это критичный по скорости участок кода? В одном из следующих релизов, когда SIMD/ASM стабилизируются, эта библиотека обновится и выдаст скорость на нужном уровне.
Так не все же, а только те, где нужен SIMD/ASM.
Rust — это не только более безопасная работа с памятью, а и вообще с ресурсами. Не говоря уже о явном контроле за ходом исполнения (control flow), отсутсвию null pointer exception, а также других особенностях языка, нацелленых на безопасность.
ozkriff
Если есть какие-то серьезные наработки + реальная перспектива использовать ржавчину "в продакшене", то, может, стоит отметиться в подобной теме: "Showcasing Rust in production; are you using Rust in production?"? Типа "нам очень хочется, но вот мешают такая-то и такая-то конкретные штуки". Как я понимаю, команда ржавчины тогда вполне может несколько перераспределить приоритеты задач. Все-таки каждая "история успеха" и организация-друг это большой бонус в продвижении языка.
ozkriff
обратно-совместимым же :)
Halt
ozkriff
https://github.com/rust-lang/rfcs/blob/master/text/1522-conservative-impl-trait.md
https://github.com/rust-lang/rust/issues/34511
https://github.com/rust-lang/rust/pull/35091
https://www.reddit.com/r/rust/comments/4xdghn/merged_implement_impl_trait_in_return_type/
Halt
Ну то есть они решили взять за основу оригинальное предложение по impl Trait и выкатить его, основательно укоцав. В принципе далеко не худший вариант, с учетом сохранения совместимости.