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

И если старых C++ников от перехода на Rust может удерживать много разных факторов, то вот новички вполне могли бы Rust-ом и заинтересоваться.

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

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

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

Как я уже сказал выше, речь идет не только про вчерашних студентов, сколько про людей, мало работавших с нативным кодом. А к производительности нативного кода, как мне видится, сейчас интерес растет. Отсюда и успех Go. Отсюда и истории, как народ переписывает проекты с Python-а на Go. Или расшивает узкие места в Go на том же Rust-е.

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

А почему Go плох для замены C/C++ ? В версии 1.8 время GC уменьшено до сотни микросекунд, и работа по еще большему уменьшению времени работы GC продолжаются.

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

А почему Go плох для замены C/C++ ?

Не могу говорит за C, а вот по поводу C++ проще сказать, чем Go хорош:

  • ну очень быстрая компиляция;
  • средства для приведения кода к общему виду в составе самого компилятора;
  • большое количество батареек изкаропки;
  • язык для дебилов (во всех смыслах этого слова), научить кодить на Go можно и обезъяну за неделю;

В остальном крайне убогий язык. Как эффективный клей на замену Python-у, может и хорош. Как замена C++ в проектах масштаба MongoDB, Chrome или Photoshop-а... Что-то я себе слабо такое представляю.

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

Го все же немного из другой оперы, принципиальных отличий от питонов там нет. К тому же язык экстремально упрощенный. Чтобы подступиться к Rust требуется уже новый уровень скиллов, язык то не проще C++. И тут важна как раз цена вопроса. Изучать язык просто для прокачки мозгов очень мало кто захочет. Так что вангую проблему накопления критической массы кодеров.

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

А к производительности нативного кода, как мне видится, сейчас интерес растет. Отсюда и успех Go

А мне видится, что Go просто закрыл проблему сложности многопоточных програм. Будь Go интерпретируемым, но с тем же синтаксисом - тоже бы выстрелил (с еще большей силы - никто не любит конпелять). Будь у ерланга синтаксис попроще - не было бы никакого Go

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

Про убогость могу сказать, что добавить в язык что-то намного легче, чем убавить (обратная совместимость).

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

Го все же немного из другой оперы, принципиальных отличий от питонов там нет.

Вот не знаю откуда это пошло, но Го похож на питон примерно никак. Говорю как человек, который писал на обоих.

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

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

Чем закрыл? Он не предотвращает data races.

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

Го похож на питон примерно никак

Оба императивные языки с GC, этого достаточно.

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

Так сломали только в этом релизе. Небось выкатят 1.15.1. Уже один раз было.

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

Ну значит Go не закрывает проблему многопоточности, а решает ее в мере достаточной для практического применения. Главное, что многопоточность стала до безобразия простой и разработчики наконец избавились от груза прошлых веков: апача, fastcgi, синхронизации через redis, етц

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

Rust пока не умеет неблокирующие операции в рамках одного потока (и не факт что будет уметь), так что сравнивать с Go его некорректно

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

Кстати да, можно ссылку на то, что ты считаешь невозможным?

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

Rust пока не умеет неблокирующие операции в рамках одного потока (и не факт что будет уметь), так что сравнивать с Go его некорректно

На самом деле умеет, просто в Rust это реализовано на через сторонние библиотеки, например в https://tokio.rs/.

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

И что мешает сделать event loop в rust?

Каким же образом? Mio, tokio и компания не столь элегантны, как горутины. При этом еще довольно сыры и не обросли нужной функциональностью. Iron, флагманский rust web framework, умеет только в тредпул. Сравните это с изобилием сетевых штук на Go

Дайте ссылку на доку о том, о чём вы пишите

О чем конкретно?

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

А на что мне futures без задач? А откуда возьмутся решения (http, драйвера к БД, websockets, fs, итд итп) на tokio, если это отдельная библиотека, а не сердце языка? В питоне тоже уже лет 10 есть сторонние решения для асинхронщины - и чо? Не стандартно, не элегантно - не нужно

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

откуда возьмутся решения (http, драйвера к БД, websockets, fs, итд итп) на tokio

Весь код пишут люди.

если это отдельная библиотека, а не сердце языка?

Если это «общепринятая» библиотека (а дело к тому идет), то какая разница между ней и «сердцем языка»? Правильно, только в том, что ее можно модифицировать, не меняя сам язык.

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

Если это «общепринятая» библиотека (а дело к тому идет)

Будем надеяться. Но мне отчего-то верится с трудом

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

Но мне отчего-то верится с трудом

Почему? У Hyper поддержка tokio уже в мастере, биндинги к PostgreSQL тоже шевелятся в этом направлении.

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

Ну вы почитайте самого Пайка, откуда у Google взялась потребность в Go. Для C++ и для Java достаточного количества толковых программистов не хватало. А Python, на котором тамошние индусы могли нормально что-то делать, был слишком тормозной. Вот и сделали Go, который простой, подходит для индусов, гораздо быстрее Python-а и успешно заменяет Python на Google-овских задачах.

Потом это же на примере Dropbox-а повторилось, когда они Python-овский код на Go переписывают.

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

если это отдельная библиотека, а не сердце языка

Даже в питоне многое не является частью стандартной библиотеки.
В расте минималистичная стандартная библиотека, это позволяет не накапливать лишнее legacy. Несколько дополнительных крэйтов поддерживаются разработчиками языка, остальное — стороннее.

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

О, уже запилили. Приятно. Последний раз когда смотрел - не было

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

То есть у гугла не было денег нанять толковых прогеров и они написали язык для бестолковых?

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

У Google и других больших компаний проблема не в деньгах, проблема в том, что толковых прогеров в количествах десятков тысяч штук в одном месте не собрать. Изрядный процент от этих 20K разработчиков будет бестолковым. И не потому, что совсем уж тупые, а потому, что занимаются никому не интересной рутиной.

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

https://crates.io/search?q=tokio

Капля в море по сравнению с либами на Go. Напомню, что абсолютно все Go-либы написаны с учетом CSP - в этом его главное преимущество

Node.js это «отдельная библиотека»

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

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

Mio, tokio и компания не столь элегантны, как горутины.

Воу-воу-воу. Держите этого фанбоя.

futures-rs зарелизился всего месяц назад, ясен пень на нём еще ничего нет.

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

Для C++ и для Java достаточного количества толковых программистов не хватало

А в Java и C++ тоже проблемы с неблокируемостью и многопоточностью. Вы думаете java-сеньоры от хорошей жизни переходят на скалу? Я думаю переходят из-за akka - благодаря синтаксису скалы можно писать акторы почти так же красиво, как горутины. Но так-как сам язык сложный и имеет массу родовых проблем, то это удовольствие не для каждого. (Это мое мнение. Оно может не соответствовать истине:)

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

Воу-воу-воу. Держите этого фанбоя

Я фанат Rust и не любитель Go. Но когда король голый - надо говорить что король голый

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

А что там читать?

Я вам сам прочитаю: «Напомню, что абсолютно все Go-либы написаны с учетом CSP - в этом его главное преимущество»

Разработчик tokio может слиться, либа застагнировать. С Го такого не произойдет, т.к. горутины в самом языке

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

Но когда король голый - надо говорить что король голый

Только ни тогда, когда вы сравниваете двух разных королей.

Отсутствие большого количества либ под rust обусловлено тем, что ему чуть меньше двух лет. И с этим ничего не поделать.

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

в этом его главное преимущество

Преимущество в том, что они завязаны на одну единственную реализацию? Да, в этом есть плюсы, но я бы не назвал это преимуществом.

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

С Го такого не произойдет, т.к. горутины в самом языке

Зная любовь гугла к закапыванию своих проектов - я бы не был так уверен.

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

они завязаны на одну единственную реализацию?

В этом его недостаток. А в том, что я описал - его преимущество. В чем проблема?

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

А в Java и C++ тоже проблемы с неблокируемостью и многопоточностью.

Не знаю, как у Java-сеньоров, а у меня в C++ проблем с неблокируемостью и многопоточностью нет. Но я велосипедостроитель, я себе наделал удобных инструментов ;)

Что до Scala, то, имхо, хайп вокруг нее стихает. Ибо язык больно сложный. А Akka вполне себе и из Java используется. Тот же Lightbend (бывший Typesafe) сейчас больший акцент именно на Java-решения делает.

Но у Java, применительно к Go, есть другая проблема: жирная VM и еще более жирный runtime. Недавно где-то проскочила инфа о том, как народ мигрировал со Scala на Go. Там одно из хороших последствий было в том, что Docker-образы для приложения на Go занимали с десяток мегабайт, а для приложения на Scala — несколько сотен мегабайт.

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

из-за akka

В мире JVM есть и другие интересные штуки. Вроде Vert.x или Quasar.

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

Отсутствие большого количества либ под rust обусловлено тем, что ему чуть меньше двух лет

Опять же, дело не в либах, а в основе. node.js не просто так стал популярным, а потому, что js имеет eventloop и на этот луп натянули сеть и ФС. Rust в этом конкретном вопросе не соответствует духу времени и из-за этого может слиться. И никакие внешние асинхронные нашлепки не помогут, как не помогли питону или рубям

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