Анонс Rust 1.7

Автор оригинала: Rust Core Team
  • Перевод
Мы рады объявить новую версию Rust, 1.7. Rust — системный язык программирования, нацеленный на безопасную работу с памятью, скорость и параллельное выполнение кода.

Как всегда, вы можете установить 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 the cargo rustc subcommand] позволяет указать профиль, согласно которому должны браться зависимости времени разработки (dev-dependencies) во время тестирования и т.д.

Участники версии 1.7


144 человека участвовало в разработке 1.7. Большое спасибо!

Список участников в 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
  • Björn 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 Desré
  • fbergr
  • Felix Gruber
  • Felix S. Klock II
  • Florian Hahn
  • Geoff Catlin
  • Geoffrey Thomas
  • Georg Brandl
  • ggomez
  • Gleb Kozyrev
  • Gökhan Karabulut
  • Greg Chapple
  • Guillaume Bonnet
  • Guillaume Gomez
  • Ivan Kozik
  • Jack O’Connor
  • Jeffrey Seyfried
  • Johan Lorenzo
  • Johannes Oertel
  • John Hodge
  • John Kå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 Löbel
  • Masood Malekghassemi
  • Matt Brubeck
  • Mátyás 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
  • Sébastien Marie
  • Seo Sanghyeon
  • Sergey Veselkov
  • Simonas Kazlauskas
  • Simon Sapin
  • Stepan Koltsov
  • Stephan Hügel
  • Steve Klabnik
  • Steven Allen
  • Steven Fackler
  • Tamir Duberstein
  • tgor
  • Thomas Wickham
  • Thomas Winwood
  • Tobias Bucher
  • Toby Scrace
  • Tomasz Miąsko
  • tormol
  • Tshepang Lekhonkhobe
  • Ulrik Sverdrup
  • Vadim Petrochenkov
  • Vincent Esche
  • Vlad Ureche
  • Wangshan Lu
  • Wesley Wiser

Поделиться публикацией

Похожие публикации

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 27

    –1
    144 человека участвовало в разработке 1.7. Большое спасибо!

    Интересно, сколько из них присутствует на Хабре? ;)
      +3
      По крайней мере один: Nikita Baksalyar — это greedykid ;)
        +3
        По крайней мере два.
          0
          Не участвовал в 1.7, но мои нано-правки есть в 1.5, 1.6 и pre-1.0. В феврале только cargo правил немного.
      0
      std::panic пока не стабилизировался, буду дальше жить на nightly.

      Интересно, а как murmur3 по сравнению с sip и fnv?
        +1
          0
          О, спасибо, выглядит вкусно. Забавно, что реализация xxh32 для java лежит рядом с lz4, который очень приятный и шустрый алгоритм сжатия.
        –3
        Интересно в какой нише в итоге закрепится Rust. Очевидно, что он в итоге вытеснит Си, кроме случаев с легаси кодом. Если это произойдет, то главный козырь С++ — совместимость с Си на котором дофига библиотек тоже будет потерян и часть людей пишущих на С++ перейдет на Rust, а часть скорее всего на какой-то новый более высокоуровневый язык, который даст возможность бесшовной интеграции с Rust.

        Думаю в итоге, лет через 5 Linux и Windows начнет загибаться под напором чего-то вроде https://github.com/redox-os
          –4
          Интересно, почему люди минусуют комментарий — человек рассуждает абсолютно верно.
            +10
            Наверное, потому что заявление про загинающиеся Linux & Windows из-за ОС на rust (почему не на go? php?), скажем так, чрезвычайно смелое. Взять браузеры — Firefox загибается оттого, что есть Servo или что в нём появляются куски кода на rust? Нет же.
              –3
              Ну про слова про ОС я с вами согласен, а вот про то, что раст замена C — это очень верно.
                +1
                В очень ограниченном масштабе — возможно. Во многих случаях переписывать тонны сишных библиотек никто не будет, т. к. это многие человеко-годы.

                Но ниша C, как портабельного ассемблера остаются точно, т. к. до сих пор существует множество архитектур под которые есть проприетарные компиляторы C, но нет поддержки в llvm.
                  +1
                  Ну вот мне, например, не нравится исходный и ваш комментарии. Раст пока не очень производительный по сравнению с С, если посмотреть на бенчмарки. И, мне начинает казаться, никогда таким не станет. Хотя бы из-за проверок на выход за границы массива, которые никак не отключить (если я не ошибаюсь). И, например, в числодробилках (а ля научных приложениях), где таких проверок будет очень много, я предпочту все еще С/С++, хотя раст мне поначалу даже нравился. Плюс язык не выглядит уже намного проще С++. Писать на нем, как оказалось, не настолько и удобно. Как оказалось, опять же, иногда unsafe code может быть необходим (да, связный список), хотя вначале разработчиками как бы заявлялось, что любую программу в принципе можно написать без unsafe.
                    +2
                    Хотя бы из-за проверок на выход за границы массива, которые никак не отключить (если я не ошибаюсь)

                    Ошибаетесь, есть методы.

                    Как оказалось, опять же, иногда unsafe code может быть необходим (да, связный список)

                    Этот unsafe code изолируется в модуле, реализующем связный список и не торчит потрохами во всех остальных модулях. Причём, благодаря мономорфизации достаточно реализовать этот список один раз в стандартной библиотеке, чтобы не париться далее. То, что часть стандартной библиотеки (или сторонних библиотек) использует unsafe вас, как разработчика конечного приложения или downstream библиотеки, не должно волновать слишком сильно.
                      +3
                      > Плюс язык не выглядит уже намного проще С++

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

                      И, кстати, почему «уже»?
                    –1
                    Мне вот тоже интересно. Кто будет поддерживать ядро к примеру линуксе, когда основные мейнтейнеры состарятся, а людей пишущих на с все меньше. Хотя может их просто меньше в пропорции. А так-то хватит
                      +2
                      В gcc вот разрешили на плюсах писать, в Linux'е просто в один прекрасный день тоже разрешат, а там и до модулей на Rust недалеко. А там уж и основу когда-нибудь переделают на чем-то более современном. Никто в здравом уме не выкинет работающую ось.
                        –1
                        В ядро Linux не будут принимать ничего связанного с C++. Прихоть одного финского товарища.
                          +1
                          Эта «прихоть» продиктована чисто практическими соображениями. В проекте такой сложности и с такими требованиями к надёжности, как в Linux, C++ будет как скальпель с атомной батарейкой, оптическим прицелом и тепловым автонаведением: всё это можно отключить, но пульт от скальпеля есть даже у уборщицы, и никто не застрахован от внезапной кровавой бани.
                  –2
                  >Интересно, почему люди минусуют комментарий
                  Тут очень много верующих. Верят в то, что Linux вечен и непогрешим.

                  >из-за ОС на rust (почему не на go? php?)
                  Как вы себе ОС на Go или PHP представляете? Судя по тому ваш коммент заплюсовали куча народу пишет ОС на PHP.

                  >Взять браузеры — Firefox загибается оттого, что есть Servo или что в нём появляются куски кода на rust?
                  Ну понемногу перепишут на Rust. В случае с Linux это невозможно будет. Именно поэтому очевидно в ближайшем будущем выстрелит какая-то новая ОС на Rust.

                  А про тонны сишных библиотек — ерунда. Все ключевые библиотеки быстро перепишут, а оставшийся мусор будет тупо как легаси висеть. Как сейчас Fortran.
                    0
                    Как вы себе ОС на Go или PHP представляете?
                    На Go очень можно представить. Просто ввести runtime поддержку в ядро. JavaVirtualMachine, Lisp machine, HaskellVirtualMachine, HaskellOS.
                      +1
                      Потому что раст фокусируется на производительности помимо безопасности. Он не требует рантайм GC, у него детерминированная сборка мусора и его хваленые нулевые абстракции.
                    +1
                    Swift? Arc почти бескровно мапится на систему типов Swift'а, Trait'ы на Protocol'ы, а Enum'ы и там и там одну и ту же концепцию реализуют.
                      +1
                      Ответ на ваш вопрос
                      http://www.redox-os.org/book/book/introduction/will_redox_replace_linux.html
                        –1
                        Он написал «чего‐то вроде», а не «именно redox». Кроме того, нет никаких гарантий, что мнение автора по этому поводу не изменится. Или что его мнение вообще будет волновать тех, кто начнёт заменять linux на redox, если последняя дорастёт до нужного уровня. Такое заявление не значит абсолютно ничего, только время покажет его соответствие действительности.

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

                    Самое читаемое