LINUX.ORG.RU

Rust 1.15

 


2

10

Представлен релиз Rust 1.15 — системного языка программирования, нацеленного на безопасную работу с памятью, скорость и параллельное выполнение кода. В этот релиз вошли 1443 патча.

Если у вас уже установлена предыдущая версия Rust, то обновиться до Rust 1.15 очень легко:

$ rustup update stable
или же следуя инструкции на соответствующей странице.

Стабильная версия, наконец-то, увидела долгожданную возможность: пользовательские расширения (custom derive)! К примеру, в Rust вы всегда могли автоматически реализовать некоторые типажи через атрибут derive:

#[derive(Debug)]
struct Pet {
    name: String,
}
В примере выше была определена реализация типажа Debug для структуры Pet с использованием минимального кода. Однако, это работало только для тех типажей, которые являлись частью стандартной библиотеки; пользователям это было недоступно. С версии Rust 1.15 это стало доступно. Это значит, что если вы захотите преобразовать структуру Pet в JSON, это так же просто, как добавить Serde в ваш Cargo.toml:
[dependencies]
serde = "0.9"
serde_derive = "0.9"
serde_json = "0.9" 
и добавить новый типаж к Pet:
#[macro_use]
extern crate serde_derive;

extern crate serde_json;

#[derive(Serialize, Deserialize, Debug)]
struct Pet {
    name: String,
}

fn main() {
    let pet = Pet { name: String::from("Ferris") };

    let serialized = serde_json::to_string(&pet).unwrap();
    println!("serialized = {}", serialized);

    let deserialized: Pet = serde_json::from_str(&serialized).unwrap();
    println!("deserialized = {:?}", deserialized);
}
Это выведет:
serialized = {"name":"Ferris"}
deserialized = Pet { name: "Ferris" }
Другой часто используемый вариант — Diesel (новая версия 0.10.0 которого представлена вслед за Rust 1.15). Допустим, у нас есть база данных, состоящая из Pet. Мы можем сделать выборку следующим образом:
// some extern crate and use lines elided here

#[derive(Queryable)]
struct Pet {
    name: String,
}

fn main() {
    use diesel_demo::schema::pets::dsl::*;

    let connection = establish_connection();
    let results = pets
        .limit(5)
        .load::<Pet>(&connection)
        .expect("Error loading pets");

    println!("Displaying {} pets", results.len());
    for pet in results {
        println!("{}", pet.name);
    }
}
Другие примеры с использование Diesel можно посмотреть на сайте.

Такого рода библиотеки являются очень мощными, но полагаются на пользовательские расширения для эргономики. Хотя эти библиотеки и работали прежде на стабильной версии Rust, пользоваться ими было не так удобно, и пользователи предпочитали работать на ночных версиях Rust «из-за Serde и Diesel». Пользовательские расширения являются одними из самых широко-используемых возможностей в ночных версиях Rust. Таким образом, в июле прошлого года была начата работа над RFC 1681 для реализации данной возможности. В августе RFC был принят, претерпел большое количество работы и тестирования и, в итоге, был включен в эту стабильную версию.

Научиться писать свои собственные расширения можно в соответствующей главе книги «The Rust Programming Language».

Хотя больше всего упоминаний в рамках данной возможности пришлось на «Serde и Diesel», есть много других крутых возможностей, которые можно делать при помощи пользовательских расширений: например, derive-new. Ещё больше можно увидеть, посмотрев список обратных зависимостей пакета syn. (syn очень важен для написания пользовательских расширений; для большей информации, смотрите соответствующую главу книги, ссылка на которую приведена выше). Пользовательские расширения были так же известны под названием «макросы 1.1», так как включают в себя основополагающую инфраструктуру для поддержки ещё более мощных возможностей во время компиляции в Rust, под названием «макросы 2.0». Ожидаем услышать больше новостей в этой сфере в будущих релизах.

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

Система сборки Rust была переписана на Rust с использованием Cargo. Теперь это основная система. Процесс был долгим, но наконец-то принес свои плоды. Вся разработка Rust происходит в основной ветке с использованием новой системы сборки, начиная с декабря прошлого года и показывает хорошую работу, ещё один показатель зрелости Cargo. Уже подготовлен PR для полного удаления всех Makefile-ов к версии Rust 1.17. Это позволит rustc напрямую использовать пакеты с crates.io в компиляторе, как это делается в других проектах на Rust.

В Rust появилась поддержка новых платформ 3 уровня: i686-unknown-openbsd, MSP430, и ARMv5TE.

Компилятор получил ряд улучшений производительности. Работы над производительностью компилятора продолжаются от релиза к релизу и в будущем ожидаются ещё больше улучшений.

В качестве незначительного улучшения, ?Sized теперь можно использовать в утверждении where. Другими словами:

struct Foo<T: ?Sized> {
    f: T,
}

struct Foo<T> where T: ?Sized {
    f: T,
}
Вторая форма теперь принимается, и равнозначна первой.

Более подробный список изменений.

Стабилизация библиотек

Алгоритм slice::sort был переписан и теперь гораздо-гораздо быстрее. Применяется гибридная сортировка слиянием, вдохновленная Timsort. Раньше применялась простая сортировка слиянием.

Если у вас имеется Vec<T> где T: Copy с вызовом extend на него, ваш код теперь будет гораздо быстрее.

Говоря о быстродействии, chars().count(), chars().last(), и char_indices().last() теперь тоже быстры!

Китайские символы теперь правильно отображаются в fmt::Debug.

Также были стабилизированы следующие функции:

Более подробный список изменений.

Возможности Cargo

Cargo теперь будет выдавать предупреждение, если в верхнем уровне пакета будет файл с названием build.rs, но не будет аннотации build = "build.rs". Это делается из соображения совместимости, так как предполагается использование файла build.rs в верхнем уровне пакета в качестве файла сборки.

В этом релизе, скрипты в Cargo больше не имеют доступа во время сборки к переменной среды окружения OUT_DIR через env!(«OUT_DIR»). Теперь проверку переменной надо осуществлять во время выполнения через std::env. Установка значения переменной во время сборки было ошибкой и некорректной при кросс-компиляции. Проверьте свои пакеты и обновите на использование std::env.

Команда cargo test получила поддержку флага --all, что полезно при работе с рабочими пространствами.

Появилась возможность статической компиляции с использованием MSVC CRT на Windows, и статического связывания OpenSSL на Mac OS X.

Более подробный список изменений.

Страница благодарности

Для выражения благодарности авторам и помощникам, которые делают Rust лучше, запущена новая инициатива «Thanks!» — страница с благодарностью людям, которые внесли вклад в Rust. Страница доступна по адресу https://thanks.rust-lang.org/ (или https://♥.rust-lang.org). Список авторов и помощников за всё время, по количеству коммитов, можно посмотреть здесь: https://thanks.rust-lang.org/rust/all-time. В Rust 1.15 всего был сделан вклад со стороны 137 людей.

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

★★★★★

Проверено: jollheef ()
Последнее исправление: Deleted (всего исправлений: 2)

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

Ясно. За джавой не слежу, тонкостей не знаю. Просто мне кажется многие недооценивают проблему, решенную в Go и Erlang

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

ыыы

2047 год. Гугл, майкрософт и эпл пишут свои ОСи на Javascript (в гугле код пишет нейросеть, MS пытается выпилить winapi из Windows 20, у эппла своя закрытая, несовместимая ни с чем версия JS)

@

Линуксоиды размышляют о целесообразности перехода с c89 на c90

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

Просто мне кажется многие недооценивают проблему, решенную в Go и Erlang

Они решают разные проблемы.

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

2047 год. Гугл, майкрософт и эпл пишут свои ОСи на Javascript

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

в гугле код пишет нейросеть

Ну разве что так.

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

в гугле код пишет рехнувшаяся нейросеть

Только так.

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

Go и Erlang не только решают разные проблемы, но и построены на разных базисах. Go — это CSP, Erlang — это actor model (хотя сам Армстронг про это никогда и не говорил). Не смотря на то, что CSP и Actor Model (в теории) могут выражаться друг через друга, все-таки программирование с их использованием на практике несколько отличается. Дело усугубляется еще и тем, что каналы в Go типизированные.

Так что Go и Erlang сильно разные. Не очень понятно, что именно вы подразумевали, увязывая их друг с другом.

eao197 ★★★★★
()

Представлен релиз Rust 1.15 — системного языка программирования, нацеленного на безопасную работу с памятью, скорость и параллельное выполнение кода.

скорость

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

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

К тому времени JS вберет в себя все возможности и парадигмы из всех языков, так что другие отомрут за ненадобностью :)

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

Ноги растут, насколько я могу понять (своими скудными познаниями архитектуры ОС) из того, что стэк в линуксе фиксированного размера, и из того, что ядро неэффективно переключается между тредами. Erlang и Go позволяют держать тысячи коннекшонов при минимальном потреблении памяти и не сжирая проц на переключениях контекста (Но это не точно)

Такую проблему решают

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

Вообще-то, эрланг был придуман совсем для другого. А именно: он позволяет чинить и менять приложение на живую, не останавливая.

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

Вам виднее. Но возможность создавать в нем тысячи (недо)процессов и весело ими жонглировать, там, ИМХО, самое главное практическое преимущество

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

Линуксоиды размышляют о целесообразности перехода с c89 на c90

Бери выше. В стане чисто-сишников, а вот уже 2-3 года идут жаркие споры о стандарте C11 (2011 г.). Где кстати, на языковом уровне включена многопоточность.

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

К тому времени C++ вберет в себя все возможности и парадигмы из всех языков

Fixed. И JS при таком подходе тоже скоро начнут ненавидеть все, кроме потративших на его изучение N лет. N >= 5

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

идут жаркие споры о стандарте C11 (2011 г.)

Скорее не споры, а отдельные выкрики из толпы «на*** он нам нужОн, ваш с11!»

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

Erlang появился раньше, чем Линус занялся разработкой Linux-а.

Ну и обилие конекшенов не имеет отношения к принципам, которые легли в основу Erlang-а и Go.

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

Блин, самая точная характеристика Rust'а, что я видел.

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

И хрен пойми о чем там спорить, 11й стандарт же конфетка

Старым пердунам не нравится.

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

В основу Erlang-а легла попытка сделать язык для разработки надежных приложений для телекома. Отсюда там легковесные процессы внутри специализированной VM, обмен асинхронными сообщениями и динамическая типизация. В сети есть объемная PDF-ка за авторством Джо Армстронга, вроде бы под названием History of Erlang Language. Интересное чтение.

Go же, насколько я помню, является развитием языка Limbo из Plan9, где Пайк и опробовал использование CSP-каналов на практике.

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

Скорее не споры, а отдельные выкрики из толпы «на*** он нам нужОн, ваш с11!»

Но кричат ведь авторитеты.

А универах преподы чмырят ленивых студентов согласно этому стандарту.

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

Но кричат ведь авторитеты

Как видно из истории с Эриком, авторитеты тоже любят пиариться скандальными резонансными статейками

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

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

Не знаю, насколько я неопытный разработчик, но деньги я почти всегда зарабатывал джавой, хотя знаю и C и C++ 10 лет назад знал неплохо. Rust на начальном уровне изучил за пару дней. Правда не уверен, что на 100% готов самостоятельно решать все проблемы со всякими ownership-ами, но с помощью SO скорее всего всё решу. unsafe правда не трогал ни разу. Для интереса писал небольшой парсер (несколько сотен строк), с автогенерируемым кодом (из макросов Rust-а), всё получилось и проблем практически не было. Т.е. если бы мне кто-то был готов платить деньги, скорее всего я бы смог решать задачи на Rust.

Но если человек не может писать на C, вручную управлять памятью, скорее всего ему будет трудно. Тут даже не в Rust дело, а просто в низкоуровневом программировании.

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

«когда собаке делать нечего, она яйца лижет». вот так же и со скалой. ничего принципиально нового akka не даёт и всё это реализуется через существующие в java среде механизмы.

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

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

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

Будь у ерланга синтаксис попроще - не было бы никакого Go

Elixir вам в руки. Язык написаный на базе BEAM (той же виртуальной машины, что Erlang), по сути является функциональной модернизацией Erlang, примерно как Scala по сравнению с Java.

Берем Phoenix если нужен обычный веб-фреймворк (более-менее клон Ruby on Rails), а дальше используем актор-модель OTP модель целиком основанную на Erlang, и выводим сложные задачи в отдельные актеры, изящно избегая проблему монолитизации присущей тому же Rails. Ну и будучи полностью функциональным языком, многие проблемы с многопточностью решаются очень элегантно.

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

А char чем обозначать будем? Ещё какие-нибудь кавычки?

В современном программировании char не используется так часто, чтоб под него выделяеть аж отдельный символ на клавиатуре. Будет Char::from('a') или 'a'.to_char.

По сравнению, и сменяемые и несменяемые строки используются в Rust повсеместно. Char я не встречал в коде практически нигде.

gene1
()

Что-то я ни слова не понял...

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

Go же, насколько я помню, является развитием языка Limbo из Plan9, где Пайк и опробовал использование CSP-каналов на практике.

Каналы в Plan 9 были опробованы в Alef (автор Phil Winterbottom), Limbo уже был потом в Inferno.

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

Возможно, за историей CSP не следил. Спасибо за информацию.

eao197 ★★★★★
()

Дефолтных аргументов все так и нет? :)

Я все жду когда же они появятся. Мне просто интересно.

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

Я все жду когда же они появятся. Мне просто интересно.

А если бы еще вариативные аргументы появились, возможно, не нужно было бы использовать маркос чтоб вывести на экран «Hello World» :-)

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

Сделать например «строка» с двойными кавычками - сменяемой, а 'строка' с одной - несменяемой, так и не додумались.

Совершенно не к чему было додумываться до такого. Могли бы и автоматическое преобразование из &str в String реализовать, c++ перед глазами был. Да даже без автоматического преобразования, Rust в принципе умеет выводить тип численных литералов из типа левого операнда присваивания, так что могли бы расширить это на строки, чтоб строка в двойных кавычках в зависимости от контекста означала то или другое. Вот только ни к чему это. Но если кому-то принципиально, ничто не мешает макрос забубенить, будет s!(«aaa»).

А вообще, в реальной жизни конкретно преобразование литерала в String не особо часто нужно. String - тип владеющий, неявно не копируемый, так что параметр такого типа требовать не принято, за редким исключением, функции будут брать слайс из строки. А если функция может принимать позаимствованный слайс, она и статический возьмёт, владеющую строку, если нужно, уже внутри себя создаст. Так что снаружи foo(«bar») никакого .to_owned() не пишется, и кавычки особые тоже не нужны, а внутри функции foo у нас уже не литерал, а вполне себе &'a str, так что особые кавычки тут ничем бы не помогли.

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

Знакомый колобок... Да это же школьник-кун!

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

Могли бы и автоматическое преобразование из &str в String реализовать

С неявным выделением памяти?

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

Если бы. Проблема серьезная. Скажем, есть проект, в котором используется веб-фреймворк на futures-rs. Понадобился асинхронный доступ к какой-нибудь БД, а он есть только на MIO. Через пару лет futures забросят и будет хайпиться какой-нибудь promises-rs. А пользователь этих либ будет пытаться усидеть на трех стульях одновременно, соединять несоединимое

В Си такой же бардак с асинхронщиной. Кто-то пишет либу на select, кто-то на poll, кто-то с libevent, кто-то с libev, с libuv. В mongoose и libmicrohttpd свои «фреймворки» поверх select/poll. В hiredis адаптеры подо всё что можно. Mosquitto - libuv. Каждый второй реализует конечные автоматы и очереди (велосипедит свой libuv). И весь этот хлам почти невозможно соединить друг с другом

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

Поэтому вершина асинхронного програмирования на си - монолитная ***ня, под которую почти нереально писать модули (вместо этого вам предлагают IPC по http reverse proxy и многие даже нахваливают этот подход)

Без асинхронщины в синтаксисе или в стдлиб, раст вполне может ожидать та же участь

makoven ★★★★★
()
Последнее исправление: makoven (всего исправлений: 4)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.