Как всегда, вы можете установить Rust 1.7 с соответствующей страницы официального сайта, а также посмотреть подробный список изменений для версии 1.7 на Github. Этот релиз включил в себя 1300 патчей.
Что вошло в стабильную версию 1.7
Этот релиз в основном нацелен на библиотеки. Хотя у нас есть несколько возможностей языка, которые мы готовим для будущих релизов, период, в который была разработана версия 1.7, включал праздники, поэтому люди меньше проводили время в комментариях на GitHub и вместо этого уделяли внимание близким.
Стабилизация библиотек
Примерно 40 библиотечных функций и методов стабилизировано в 1.7. Один из крупнейших стабилизированных API — поддержка пользовательских алгоритмов хэширования в стандартном
HashMap<K, V>. Раньше все хэш-словари использовали SipHash в качестве алгоритма хэширования, что обеспечивало защиту от DoS-атак по умолчанию. Однако, SipHash не очень быстр при хэшировании маленьких ключей. Алгоритм FNV гораздо быстрее для таких аргументов. Это означает, что изменение алгоритма хэширования для типов вроде HashMap<usize, V> может дать значительный прирост производительности, если вамне нужна защита от DoS.
Чтобы увидеть это на примере, вы можете взять контейнер fnv на crates.io и создать
HashMap так:extern crate fnv;
use std::collections::HashMap;
use std::hash::BuildHasherDefault;
use fnv::FnvHasher;
type MyHasher = BuildHasherDefault<FnvHasher>;
fn main() {
let mut map: HashMap<_, _, MyHasher> = HashMap::default();
map.insert(1, "Hello");
map.insert(2, ", world!");
println!("{:?}", map);
}Заметьте, что большую часть времени вам не нужно даже указывать тип хэширующего алгоритма, т.к. сработает вывод типа.
HashMap::default() — всё, что вам нужно, чтобы получить хэширование, работающее в 2 раза быстрее. Также стоит заметить, что типаж Hash безразличен к конкретному алгоритму хэширования, поэтому никаких изменений в типах, хранимых в HashMap, не нужно!Другие заметные улучшения включают:
<[T]>::clone_from_slice(), эффективный способ копировать данные из одного среза в другой.- Различные методы на
Ipv4AddrиIpv6Addrдля удобства, вродеis_loopback(), который возвращаетtrueилиfalseв зависимости от того, является ли адрес петлевым (loopback address), как описано в RFC 6890. - Различные улучшения в типе
CString, используемом в FFI. - Арифметические операции с проверками, с насыщением, или с переполнением. Они не учтены в тех сорока стабилизированных методах, которое мы привели выше. Их очень много, но они все делают одно и то же.
Подробнее смотрите замечания к выпуску.
Возможности Cargo
Сделано несколько небольших изменений в Cargo:
- Сборочные скрипты были [улучшены][improvement to build scripts], и теперь они могут точно информировать Cargo о зависимостях. Благодаря этому они выполняются заново только когда эти файлы изменяются.
- [Изменение подкоманды
cargo rustc][modification to thecargo rustcsubcommand] позволяет указать профиль, согласно которому должны браться зависимости времени разработки (dev-dependencies) во время тестирования и т.д.
Участники версии 1.7
144 человека участвовало в разработке 1.7. Большое спасибо!
- Aaron Turon
- Adam Perry
- Adrian Heine
- Aidan Hobson Sayers
- Aleksey Kladov
- Alexander Lopatin
- Alex Burka
- Alex Crichton
- Ali Clark
- Amanieu d’Antras
- Andrea Bedini
- Andrea Canciani
- Andre Bogus
- Andrew Barchuk
- Andrew Paseltiner
- angelsl
- Anton Blanchard
- arcnmx
- Ariel Ben-Yehuda
- arthurprs
- ashleysommer
- Barosl Lee
- Benjamin Herr
- Bjorn Steinbrink
- bors
- Brandon W Maister
- Brian Anderson
- Brian Campbell
- Carlos E. Garcia
- Chad Shaffer
- Corey Farwell
- Daan Sprenkels
- Daniel Campbell
- Daniel Robertson
- Dave Hodder
- Dave Huseby
- dileepb
- Dirk Gadsden
- Eduard Burtescu
- Erick Tryzelaar
- est31
- Evan
- Fabrice Desre
- fbergr
- Felix Gruber
- Felix S. Klock II
- Florian Hahn
- Geoff Catlin
- Geoffrey Thomas
- Georg Brandl
- ggomez
- Gleb Kozyrev
- Gokhan Karabulut
- Greg Chapple
- Guillaume Bonnet
- Guillaume Gomez
- Ivan Kozik
- Jack O’Connor
- Jeffrey Seyfried
- Johan Lorenzo
- Johannes Oertel
- John Hodge
- John Ka?re Alsaker
- Jonas Schievink
- Jonathan Reem
- Jonathan S
- Jorge Aparicio
- Josh Stone
- Kamal Marhubi
- Katze
- Keith Yeung
- Kenneth Koski
- Kevin Stock
- Luke Jones
- Manish Goregaokar
- Marc Bowes
- Marvin Lobel
- Masood Malekghassemi
- Matt Brubeck
- Matyas Mustoha
- Michael Huynh
- Michael Neumann
- Michael Woerister
- mitaa
- mopp
- Nathan Kleyn
- Nicholas Mazzuca
- Nick Cameron
- Nikita Baksalyar
- Niko Matsakis
- NODA, Kai
- nxnfufunezn
- Olaf Buddenhagen
- Oliver ‘ker’ Schneider
- Oliver Middleton
- Oliver Schneider
- Pascal Hertleif
- Paul Dicker
- Paul Smith
- Peter Atashian
- Peter Kolloch
- petevine
- Pierre Krieger
- Piotr Czarnecki
- Prayag Verma
- qpid
- Ravi Shankar
- Reeze Xia
- Richard Bradfield
- Robin Kruppe
- rphmeier
- Ruud van Asseldonk
- Ryan Thomas
- Sandeep Datta
- Scott Olson
- Scott Whittaker
- Sean Leffler
- Sean McArthur
- Sebastian Hahn
- Sebastian Wicki
- Sebastien Marie
- Seo Sanghyeon
- Sergey Veselkov
- Simonas Kazlauskas
- Simon Sapin
- Stepan Koltsov
- Stephan Hugel
- Steve Klabnik
- Steven Allen
- Steven Fackler
- Tamir Duberstein
- tgor
- Thomas Wickham
- Thomas Winwood
- Tobias Bucher
- Toby Scrace
- Tomasz Miasko
- tormol
- Tshepang Lekhonkhobe
- Ulrik Sverdrup
- Vadim Petrochenkov
- Vincent Esche
- Vlad Ureche
- Wangshan Lu
- Wesley Wiser
Комментарии (27)
grossws
05.03.2016 21:16std::panicпока не стабилизировался, буду дальше жить на nightly.
Интересно, а как murmur3 по сравнению с sip и fnv?
beduin01
05.03.2016 22:20-3Интересно в какой нише в итоге закрепится Rust. Очевидно, что он в итоге вытеснит Си, кроме случаев с легаси кодом. Если это произойдет, то главный козырь С++ — совместимость с Си на котором дофига библиотек тоже будет потерян и часть людей пишущих на С++ перейдет на Rust, а часть скорее всего на какой-то новый более высокоуровневый язык, который даст возможность бесшовной интеграции с Rust.
Думаю в итоге, лет через 5 Linux и Windows начнет загибаться под напором чего-то вроде https://github.com/redox-os
JagaJaga
05.03.2016 22:57-4Интересно, почему люди минусуют комментарий — человек рассуждает абсолютно верно.
withkittens
05.03.2016 23:16+10Наверное, потому что заявление про загинающиеся Linux & Windows из-за ОС на rust (почему не на go? php?), скажем так, чрезвычайно смелое. Взять браузеры — Firefox загибается оттого, что есть Servo или что в нём появляются куски кода на rust? Нет же.
JagaJaga
05.03.2016 23:18-3Ну про слова про ОС я с вами согласен, а вот про то, что раст замена C — это очень верно.
grossws
06.03.2016 00:12+1В очень ограниченном масштабе — возможно. Во многих случаях переписывать тонны сишных библиотек никто не будет, т. к. это многие человеко-годы.
Но ниша C, как портабельного ассемблера остаются точно, т. к. до сих пор существует множество архитектур под которые есть проприетарные компиляторы C, но нет поддержки в llvm.
Bas1l
06.03.2016 04:45+1Ну вот мне, например, не нравится исходный и ваш комментарии. Раст пока не очень производительный по сравнению с С, если посмотреть на бенчмарки. И, мне начинает казаться, никогда таким не станет. Хотя бы из-за проверок на выход за границы массива, которые никак не отключить (если я не ошибаюсь). И, например, в числодробилках (а ля научных приложениях), где таких проверок будет очень много, я предпочту все еще С/С++, хотя раст мне поначалу даже нравился. Плюс язык не выглядит уже намного проще С++. Писать на нем, как оказалось, не настолько и удобно. Как оказалось, опять же, иногда unsafe code может быть необходим (да, связный список), хотя вначале разработчиками как бы заявлялось, что любую программу в принципе можно написать без unsafe.
grossws
06.03.2016 05:00+2Хотя бы из-за проверок на выход за границы массива, которые никак не отключить (если я не ошибаюсь)
Ошибаетесь, есть методы.
Как оказалось, опять же, иногда unsafe code может быть необходим (да, связный список)
Этот unsafe code изолируется в модуле, реализующем связный список и не торчит потрохами во всех остальных модулях. Причём, благодаря мономорфизации достаточно реализовать этот список один раз в стандартной библиотеке, чтобы не париться далее. То, что часть стандартной библиотеки (или сторонних библиотек) использует unsafe вас, как разработчика конечного приложения или downstream библиотеки, не должно волновать слишком сильно.
ozkriff
06.03.2016 08:57+3> Плюс язык не выглядит уже намного проще С++
Я когда вижу такие фразы, думаю что говорящий не слишком глубоко плюсы знает. Бездна тонкостей и грабель, требующих очень и очень большой самодисциплины. Да, заставить код на плюсах собираться и выдавать какой-то результат, наверное, часто проще, но вот написать хороший код — уже другой вопрос.
И, кстати, почему «уже»?
zim32
05.03.2016 23:48-1Мне вот тоже интересно. Кто будет поддерживать ядро к примеру линуксе, когда основные мейнтейнеры состарятся, а людей пишущих на с все меньше. Хотя может их просто меньше в пропорции. А так-то хватит
Gorthauer87
05.03.2016 23:57+2В gcc вот разрешили на плюсах писать, в Linux'е просто в один прекрасный день тоже разрешат, а там и до модулей на Rust недалеко. А там уж и основу когда-нибудь переделают на чем-то более современном. Никто в здравом уме не выкинет работающую ось.
Wedmer
06.03.2016 11:52-1В ядро Linux не будут принимать ничего связанного с C++. Прихоть одного финского товарища.
burjui
06.03.2016 16:00+1Эта «прихоть» продиктована чисто практическими соображениями. В проекте такой сложности и с такими требованиями к надёжности, как в Linux, C++ будет как скальпель с атомной батарейкой, оптическим прицелом и тепловым автонаведением: всё это можно отключить, но пульт от скальпеля есть даже у уборщицы, и никто не застрахован от внезапной кровавой бани.
Wedmer
07.03.2016 02:59+1Вы историю этого всего читали? Это ваше мнение, а не причина неприятия плюсов Линусом.
beduin01
06.03.2016 10:18-2>Интересно, почему люди минусуют комментарий
Тут очень много верующих. Верят в то, что Linux вечен и непогрешим.
>из-за ОС на rust (почему не на go? php?)
Как вы себе ОС на Go или PHP представляете? Судя по тому ваш коммент заплюсовали куча народу пишет ОС на PHP.
>Взять браузеры — Firefox загибается оттого, что есть Servo или что в нём появляются куски кода на rust?
Ну понемногу перепишут на Rust. В случае с Linux это невозможно будет. Именно поэтому очевидно в ближайшем будущем выстрелит какая-то новая ОС на Rust.
А про тонны сишных библиотек — ерунда. Все ключевые библиотеки быстро перепишут, а оставшийся мусор будет тупо как легаси висеть. Как сейчас Fortran.
uvelichitel
06.03.2016 13:06Как вы себе ОС на Go или PHP представляете?
На Go очень можно представить. Просто ввести runtime поддержку в ядро. JavaVirtualMachine, Lisp machine, HaskellVirtualMachine, HaskellOS.
zim32
06.03.2016 13:18+1Потому что раст фокусируется на производительности помимо безопасности. Он не требует рантайм GC, у него детерминированная сборка мусора и его хваленые нулевые абстракции.
Gorthauer87
05.03.2016 23:54+1Swift? Arc почти бескровно мапится на систему типов Swift'а, Trait'ы на Protocol'ы, а Enum'ы и там и там одну и ту же концепцию реализуют.
zim32
05.03.2016 23:57+1Ответ на ваш вопрос
http://www.redox-os.org/book/book/introduction/will_redox_replace_linux.htmlZyXI
06.03.2016 00:17-1Он написал «чего?то вроде», а не «именно redox». Кроме того, нет никаких гарантий, что мнение автора по этому поводу не изменится. Или что его мнение вообще будет волновать тех, кто начнёт заменять linux на redox, если последняя дорастёт до нужного уровня. Такое заявление не значит абсолютно ничего, только время покажет его соответствие действительности.
podust
Интересно, сколько из них присутствует на Хабре? ;)
mkpankov
По крайней мере один: Nikita Baksalyar — это greedykid ;)
VadimVP
По крайней мере два.
JIghtuse
Не участвовал в 1.7, но мои нано-правки есть в 1.5, 1.6 и pre-1.0. В феврале только cargo правил немного.