LINUX.ORG.RU

Rust 1.31.0 (2018)

 , rust2018


5

10

Команда Rust объявила о выходе новой стабильной версии Rust 1.31.0, который ознаменует собой также выход новой редакции «Rust 2018». Rust — это язык программирования, который позволяет каждому создавать надежное и эффективное программное обеспечение.

Если у вас установлена предыдущая версия Rust, обновиться до Rust 1.31.0 проще всего следующим образом:

rustup update stable

Если у вас ещё не установлен Rust, то это можно сделать, загрузив с сайта утилиту rustup.

Что нового в Rust 1.31.0

Rust 2018

Данный релиз ознаменует собой выпуск редакции Rust 2018. Впервые Rust 2018 был упомянут в марте, затем в июле: прочтите их, чтобы понимать для чего нужен Rust 2018. Также, есть статья на сайте Mozilla Hacks.

Вкратце, Rust 2018 это возможность представить всю работу за последние три года в виде цельного пакета. Кроме возможностей языка, сюда входят:

  • Инструментарий (поддержка IDE, rustfmt, Clippy)
  • Документация
  • Работа различных рабочих групп
  • Новый веб-сайт

Для обозначения редакций Rust был представлен ключ edition в Cargo.toml:

[package]
name = "foo"
version = "0.1.0"
authors = ["Your Name <you@example.com>"]
edition = "2018"

[dependencies]

Значение 2018 означает, что используется редакция Rust 2018; отсутствие ключа или значение 2015 означает использование редакции Rust 2015.

Важно отметить, что каждый пакет может быть в редакциях 2015 или 2018, и они без проблем могут работать вместе. Проект под редакцией 2018 может использовать зависимости 2015, а проект 2015 использовать зависимости 2018. Это гарантирует целостность экосистемы, сохраняя совместимость существующего кода. Кроме того, существует возможность автоматической миграции кода с редакции Rust 2015 на Rust 2018 при помощи cargo fix.

Non-lexical lifetimes (NLL; Нелексические времена жизни)

В 2018 появились нелексические времена жизни, что на простом языке означает, что проверщик заимствований (borrow checker) стал умнее и теперь не отклоняет правильный код. Например:

fn main() {
    let mut x = 5;

    let y = &x;

    let z = &mut x;
}

В старых версиях этот код выдаст ошибку компиляции:

error[E0502]: cannot borrow `x` as mutable because it is also borrowed as immutable
 --> src/main.rs:5:18
  |
4 |     let y = &x;
  |              - immutable borrow occurs here
5 |     let z = &mut x;
  |                  ^ mutable borrow occurs here
6 | }
  | - immutable borrow ends here

из-за того, что время жизни действует внутри лексического блока; то есть, заимствование будет удерживаться за y, пока y не покинет пределы main, несмотря на то, что y больше не используется. Сегодня этот код скомпилируется правильно.

Другой пример:

fn main() {
    let mut x = 5;
    let y = &x;
    let z = &mut x;
    
    println!("y: {}", y);
}

Старый Rust выдаст следующую ошибку:

error[E0502]: cannot borrow `x` as mutable because it is also borrowed as immutable
 --> src/main.rs:5:18
  |
4 |     let y = &x;
  |              - immutable borrow occurs here
5 |     let z = &mut x;
  |                  ^ mutable borrow occurs here
...
8 | }
  | - immutable borrow ends here

В Rust 2018 вывод ошибки стал лучше:

error[E0502]: cannot borrow `x` as mutable because it is also borrowed as immutable
 --> src/main.rs:5:13
  |
4 |     let y = &x;
  |             -- immutable borrow occurs here
5 |     let z = &mut x;
  |             ^^^^^^ mutable borrow occurs here
6 |     
7 |     println!("y: {}", y);
  |                       - borrow later used here

Теперь, вместо того, чтобы показывать место, где y покидает пределы лексического блока, показывается место, где происходят конфликтующие заимствования. Это значительно облегчает отладку подобных ошибок.

Пока эти возможности доступны в Rust 2018, но в будущем планируется портировать их на Rust 2015.

Изменения в системе модулей

Редакция Rust 2018 привносит некоторые изменения в работу с путями, что в конечном итоге привело к упрощению системы модулей.

Вкратце:

  • extern crate больше не требуется практически во всех случаях.
  • Макросы теперь можно импортировать при помощи use вместо атрибута #[macro_use].
  • Абсолютные пути начинаются с названия пакета, где ключевое слово crate ссылается на текущий пакет.
  • foo.rs и поддиректория foo/ могут сосуществовать вместе; mod.rs больше не нужен при размещении подмодулей в поддиректории.

Полную информацию можно прочесть в руководстве.

Упрощенные правила синтаксиса времени жизни

В обеих редакциях представлены новые правила синтаксиса времени жизни для блоков impl и определениях функций. Следующий код:

impl<'a> Reader for BufReader<'a> {
    // methods go here
}
теперь может быть написан таким образом:
impl Reader for BufReader<'_> {
    // methods go here
}

'_ подсказывает, что BufReader берёт параметр, но больше нет необходимости именовать его.

В структурах времена жизни всё ещё должны быть определены, но теперь без лишнего кода:

// Rust 2015
struct Ref<'a, T: 'a> {
    field: &'a T
}

// Rust 2018
struct Ref<'a, T> {
    field: &'a T
}
: 'a добавляется автоматически. При желании, можно продолжать использовать явное определение.

const fn

Существует несколько способов определения функций в Rust: регулярная функция с fn, небезопасная функция с unsafe fn, внешняя функция с extern fn. В этом релизе появился ещё один способ: const fn, который выглядит следующим образом:

const fn foo(x: i32) -> i32 {
    x + 1
}
Функции const fn могут вызываться как регулярные функции, но вычисляются во время компиляции, а не во время выполнения. Для стабильной работы, они должны иметь детерминированный результат и в настоящее время ограничены следующим минимальным набором операций:

  • Арифметические операторы и операторы сравнения с целыми числами
  • Все логические операторы, кроме && и ||
  • Построение массивов, структур, перечислений и кортежей
  • Вызов других функций const fn
  • Задание индекса массивам и срезам
  • Доступ к полям структур и кортежей
  • Чтение из констант
  • & и * на ссылках
  • Приведение типов, за исключением необработанных указателей на целые числа

В будущем данный набор будет расширяться, подробную информацию можно посмотреть здесь.

Новые инструменты

Наряду с Cargo, Rustdoc, и Rustup, которые являются ключевыми инструментами с версии 1.0, редакция 2018 представляет новое поколение инструментов: Clippy, Rustfmt, и поддержку IDE.

Clippy является статическим анализатором кода в Rust, достиг версии 1.0 и теперь доступен в стабильной версии Rust. Установку можно произвести следующим образом: rustup component add clippy, запуск: cargo clippy.

Rustfmt является инструментом для автоматического форматирования кода Rust в соответствии с официальной стилистикой Rust. В этом релизе он достиг версии 1.0 и, начиная с этой версии, гарантируется обратная совместимость для Rustfmt: отформатированный сегодня код останется неизменным в будущем (только с опциями использованными по-умолчанию), и несёт практическую ценность при использовании с системами непрерывной интеграции (CI; cargo fmt --check). Установить Rustfmt можно следующим образом: rustup component add rustfmt, использовать: cargo fmt.

Поддержка IDE - одна из наиболее востребованных возможностей в Rust. Работы над поддержкой IDE ещё не закончены, но на данный момент уже существуют несколько высококачественных опций:

Tool lints

В Rust 1.30 были стабилизированы атрибуты инструментов, такие как #[rustfmt::skip]. В Rust 1.31 стабилизированы «анализаторы инструментов» («tool lints») наподобие #[allow(clippy::bool_comparison)], у них появилось своё пространство имён и теперь ясно к какому инструменту они относятся. Старые проверки Clippy теперь можно писать следующим образом, вам больше не нужен атрибут cfg_attr:

// old
#![cfg_attr(clippy, bool_comparison)]

// new
#![allow(clippy::bool_comparison)]

Документация

В этом году Rustdoc увидел ряд улучшений, также полностью было переписано руководство по Rust.

Рабочие группы

В этом году было объявлено о создании четырёх рабочих групп в следующих областях:

  • Сетевые сервисы
  • Приложения командной строки
  • WebAssembly
  • Встраиваемые устройства

Каждая из этих групп очень много работала над тем, чтобы сделать Rust лучше в своей области. Некоторые основные моменты:

  • Группа сетевых сервисов работает над интерфейсом Futures и async/await, который уже будет доступен в скором времени.
  • Группа командной строки работает над библиотеками и документацией для создания ещё лучших приложений для командной строки.
  • Группа WebAssembly выпустила огромное количество инструментария для использования Rust с wasm.
  • Группа встраиваемых устройств добилась поддержки разработки ARM на стабильной версии Rust.

Новый сайт

Основной сайт получил новый дизайн.

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

Добавлено множество реализаций From:

  • u8 теперь реализует From<NonZeroU8>, то же самое для других числовых типов и их NonZero-эквивалентов
  • Option<&T> реализует From<&Option<T>>, аналогично для &mut

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

  • slice::align_to и её изменяемый аналог
  • slice::chunks_exact и её изменяемый и r аналоги (такие как slice::rchunks_exact_mut) во всех комбинациях

Подробный список изменений можно посмотреть здесь.

Cargo

Cargo теперь загружает пакеты параллельно, используя HTTP/2. В связи с тем, что extern crate практически больше не требуется, было бы неудобно использовать пакет через extern crate foo as bar; Это можно сделать в Cargo.toml следующим образом:

[dependencies]
baz = { version = "0.1", package = "foo" }

или

[dependencies.baz]
version = "0.1"
package = "foo"

В примере выше, пакет foo теперь может быть использован через baz.

Подробный список изменений можно посмотреть здесь.

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

★★★★★

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

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

Здесь ты согласился, что это гогно мамонта. Потому что это интерпретация кодов возврата, который известна еще со времен, когда сишка была молодой и зеленой. Поэтому про то, что это

вообще огромный шаг вперед в теории ЯП

заливать не нужно. Это огромный шаг на одном месте.

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

А это не я заливаю. Я существо коллективное. Что сказали в срачах по го, то и транслирую)

Сеть должна быть усыпана плачами Ярославны от искалеченных into программистами

Оо. Да там целая секта. Верующих в to_owned(). И в то, что into() «передает меньше намерений»

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

А это не я заливаю. Я существо коллективное. Что сказали в срачах по го, то и транслирую)

То есть я говорю с диктофоном? Не, так не интересно.

Сеть должна быть усыпана плачами Ярославны от искалеченных into программистами

Оо. Да там целая секта. Верующих в to_owned(). И в то, что into() «передает меньше намерений»

Я просил примеры попоболи привести, а ты привел мнения разумных людей, которые вторят мне (и наоборот). ОК, спасибо.

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

А это и есть попоболь. Коллектив здравых людей 3 недели обсуждают какой из 5 способов превращения строки в строку лучше. Самый ржачный это, конечно,

"string".to_string()

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

А это и есть попоболь. Коллектив здравых людей 3 недели обсуждают какой из 5 способов превращения строки в строку лучше. Самый ржачный это, конечно,

"string".to_string()

"string_slice".to_string() — так легче понять. to_string это не в_строку, а в_String.
И, как я уже отмечал, субъективная попоболь гражданина Российской Федерации имеет мало отношения к реальной критике.

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

работу надо облегчать программисту, а не синтаксическому анализатору

А тулинг программисту не нужен, само-собой.

хорошо обученный демагог излагает клише, но не мысли

И зачем ты излагаешь клише?

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

Между прочим, до появления try! и мистера вопросика, находились индивиды, защищающие match на каждый чих

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

Даже «match на каждый чих» - это гораздо лучше, чем проброс в стиле Go.

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

Кстати, языки со сборщиком мусора очень расслабляют людей... Так как хорошо чистят память, забывая, что бывают, к примеру, всякие хендлы, файловые дескрипторы и т.д., что тоже является лимитированным ресурсом, что тоже может утекать. Мне потому RAII подход больше импонирует, тем, что можно управлять любым типом ресурса, а не только памятью.

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

Ну вообще там суть ошибки в первых строках:

prog.cc:10:54:   required from here
/opt/wandbox/gcc-8.2.0/include/c++/8.2.0/tuple:1395:33: error: no match for 'operator<' (operand types are 'const int' and 'const std::__cxx11::basic_string<char>')
  return bool(std::get<__i>(__t) < std::get<__i>(__u))
              ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~
Явно на водит на мысль, что сравниваются int и std::string ну и строчка где это, понятно, что нужно её теперь вдумчиво прочитать и очепятку найти. Clion и QtC даже до компиляции строку подсветят ;-) Ну а дальше повесть временных лет, типа что я пытался сделать вообще.

Хотя для GCC -fdiagnostics-color=always тут бы не помешал.

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

Ну вообще там суть ошибки в первых строках:

Ну суть в том, что не в первой.

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

удобно читать столбиком последовательность действий,

с чего ты взял, что то, что удобно тебе, является объективным?

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

удобно читать столбиком последовательность действий,

с чего ты взял, что то, что удобно тебе, является объективным?

Лично ты можешь писать в строку. Надеюсь, у тебя достаточно широкий монитор, чтобы в одной строке поместилась цепочка из нескольких вызовов.

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

«string_slice».to_string() — так легче понять. to_string это не в_строку, а в_String.

ну так и сделали бы to_String()

За смешение snake_case и camelCase надо забивать подсвечником прямо за компьютером. А если серьезно, твой вариант не удовлетворяет стилю оформления кода, принятого в Rust.

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

с чего ты взял, что то, что удобно тебе, является объективным?

вообще-то это я ржу над верхним регистром.

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

За смешение snake_case и camelCase

заработчиков стандартной библиотеки руст это не смущает. просто какой-то жырный троллинг сделать базовую библиотеку верхнерегистровой.

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

Да без разницы. С чего ты взял, ну и далее по твоему тексту.

какой-то жырный троллинг сделать базовую библиотеку верхнерегистровой

Этому троллингу лет больше, чем тебе.

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

Этому троллингу лет больше, чем тебе.

дурацкая манера переходить на личности.
мне rust язык нравится, между прочим.

я уже писал - для того, что-бы на него перейти надо быть готовым к блевотным ключевым словам из эпохи паскаля и заглавным буквам в стандартной либе из эпохи Mfc или VLC. кому-то это нравится, но в целом это дурной тон.

а как вам он в сравнении со swift ?

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

Такой уровень вкусовщины нехарактерен даже для лора.

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

Этому троллингу лет больше, чем тебе.

дурацкая манера переходить на личности.

А ты не воспринимай это лично. Считай это указанием на то, что mixed case в стандартной библиотеке - долгая традиция. Настолько долгая, что ну ты понял.

блевотным ключевым словам из эпохи паскаля

Назови мне десяток ключевых слов _не_ из эпохи Паскаля.

а как вам он в сравнении со swift ?

Исходя из того немногого, что я знаю о Swift, он ублюдочен. И еще меня корежит от camelCase.

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

что тебе не мешает защищать uppecase в расте.

Я знал, что ты это скажешь.

вот она объективность.

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

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

и не выдаю перлов про Паскаль и дурной тон.

ты хороший. а другие поклонники раст - пишут про забивание «прямо за компьютером» например.

dinama
()

extern crate больше не требуется практически во всех случаях.

Хоть кто-то обьяснит как? Ставлю edition=2018, они все равно везде нужны

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

и не выдаю перлов про Паскаль и дурной тон.

ты хороший. а другие поклонники раст - пишут про забивание «прямо за компьютером» например.

А разве мама не учила тебя избегать плохих и водиться с хорошими? У них можно многому научиться, например, не вырывать цитируемые фразы из контекста.

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

Cargo.toml

[package]
name = "test6"
version = "0.1.0"
edition = "2018"

[dependencies]
log = "0.4"

main.rs

use log::info;

fn main() {
    info!("Hello, world!");
}

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

Если сильно раздражает to_string и код, который ты пишешь, никто другой поддерживать и читать не будет, то можешь сделать так:

trait S: ToString {
    fn s(&self) -> String {
        self.to_string()
    }
}

impl S for str {}

И пользоваться

"string".s()
freecoder
()
Ответ на: комментарий от Virtuos86

А разве мама не учила тебя избегать плохих и водиться с хорошими? У них можно многому научиться, например, не вырывать цитируемые фразы из контекста.


ты меня убедил. fn и let это очень хорошо. и верхний регистр в стандартной либе, это не только красиво, но и удобно.

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

Я вполне успешно в питоне «взаимодействовал» с сишным наследием, не написав ни строчки на си. Благо встроенный ffi это позволяет. Тут главное не поддаться соблазну и самому ничего не накалякать на си.

В смысле на cython? Или именно на си?

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

А разве мама не учила тебя избегать плохих и водиться с хорошими? У них можно многому научиться, например, не вырывать цитируемые фразы из контекста.


ты меня убедил. fn и let это очень хорошо. и верхний регистр в стандартной либе, это не только красиво, но и удобно.

Вообще-то я ни в чем подобном никого не убеждал. И, на минуточку, ничто из перечисленного не является чем-то уникальным, всё взято из других ЯП и/или best practices программирования.

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

ты меня убедил. fn и let это очень хорошо. и верхний регистр в стандартной либе, это не только красиво, но и удобно.

Немогли сделать как в няшной сишечке! И unsafe по-умолчанию, а safe отключить потому что мне ненужен BDSM-язык для склерозников олегофренов которые не осилили указатели. Пускай на питоне пишут, там безопасно.

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

Эх, когда уже асинк/эвейт допилят до юзабельности.

А их нельзя внешней либой сделать? Как для плюсов, много лет назад, во времена великого флуда о крутом прорыве в C#, кто-то в пару десятков строк сделал макрос await на плюсах (async там не нужен — в этом варианте не надо менять сигнатуры функций и расставлять везде async-и). Может и в расте так можно?

PS: на rust не пишу, просто с интересом посматриваю со стороны.

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

Пацаны на районе засмеют. Вообще должно быть просто «string». А умный компилятор сам должен делать into()

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

Вообще должно быть просто «string». А умный компилятор сам должен делать into()

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

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

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

Относительно, в Rust своих заморочек тоже хватает. Но да, сильно меньше, чем в C и в C++.

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

Ну тогда верните кракозябру, что была до Box<>

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

Вижу, что не к чему придраться, но хочется. Были приплетены макросы, которые мало кто сам пишет. Ну-ну.

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

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

Возможно, это будет просто языковой эксперимент.

Был когда-то такой язык ioke. У его автора было несколько интересных идей. Например, что будет, если в языке методы отделять не точкой, а пробелом? А что если убрать из языка числа с плавающей точкой, а вместо них использовать рациональные дроби? И т.д. Чтобы проверить, будет ли так удобнее, он создал язык. Полтора года он его использовал. А потом подвёл итоги.

Вот, может, и в rust-е потестируют разные подходы, а потом лучшие из них добавят в C++/Java/etc.

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

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

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

Это не про rust. В нем как раз все сделано по уму. Перечитывая того же Страуструпа, постоянно ловлю себя на мысли «а вот в rust это сделано правильно».

Union / enum class из C++ - это же позорище по сравнению с enum в rust, когда надо явно вызывать деструктор и конструктор, размещая объект по указанному адресу (там пример есть в книге). А обработка ошибок? В Rust очень-очень разумная схема. И еще доведенная до совершенства семантика move, когда к старому объекту просто нет никакого доступа, вообще нет доступа. И нет лишних операций в рантайме.

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

Union / enum class из C++

Объективности ради: union — это не из C++, это из C. Помидоры нужно кидать туда.

Сравнивать С++ный enum class с Rust-овым enum-ом... Ну это от большого ума, наверное. Типа, раз ключевые слова одинаковые, то и понятия они означают одинаковые.

В Rust очень-очень разумная схема.

Это когда либо всюду Result, либо паника, которая хрен знает к чему приведет (к раскрутке стека, либо к аборту)? Очень разумно, да.

Так это же еще в Rust-е нет наследования, чтобы конструкторы базовых типов вызывались и ошибки оттуда нужно было ловить. Да и вот та же перегрузка операторов в Rust-е: там как принято об ошибках информировать? Неужели паниками?

Перечитывая того же Страуструпа, постоянно ловлю себя на мысли «а вот в rust это сделано правильно».

А это как бы ничего, что C++ 30 лет развивался эволюционным путем и Rust создавался, в том числе и с учетом всего этого опыта?

Сравнивали бы Rust с его ровесниками (хотя бы относительными), типа Ceylon, Kotlin, Go.

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

Да, именно так. И делать это надо регулярно, для каждого сложного класса, а не когда уже деваться некуда.

Ну после статических языков об этом кошмаре быстро забываешь, о том и речь.

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

А это как бы ничего, что C++ 30 лет развивался эволюционным путем и Rust создавался, в том числе и с учетом всего этого опыта?

Ничего. Мы ж не виним создателей С++ за такой дизайн. Но это не отменяет того факта что в Rust это сделано правильно. С учетом всего опыта.

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

Ну после статических языков об этом кошмаре быстро забываешь, о том и речь.

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

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

Объективности ради: union — это не из C++, это из C. Помидоры нужно кидать туда.

Сравнивать С++ный enum class с Rust-овым enum-ом... Ну это от большого ума, наверное. Типа, раз ключевые слова одинаковые, то и понятия они означают одинаковые.

Ну-ну. Меня только интересовало, как создать sum type. Одним product-type далеко не уедешь. Товарищ Бьярн привел пример в книге, добавив, что на его взгляд так делать не стоит. НО в rust-то это нормальная ситуация, и там все просто делается и просто работает!

Это когда либо всюду Result, либо паника, которая хрен знает к чему приведет (к раскрутке стека, либо к аборту)? Очень разумно, да.

Другие схемы еще хуже. Лучше уж везде прокидывать Result. Вон, у Страуструпа столько понаписано про исключения. И не только у него одного. В rust же очень простая и работающая схема.

Так это же еще в Rust-е нет наследования, чтобы конструкторы базовых типов вызывались и ошибки оттуда нужно было ловить. Да и вот та же перегрузка операторов в Rust-е: там как принято об ошибках информировать? Неужели паниками?

Кстати, да, ООП. На мой взгляд это одновременно и проклятие C++, и его одна из лучших фишек.

Растоманы поступили проще. Они взяли и позаимствовали модель объектов из haskell, сильно упростив и сам язык, и компилятор...

А это как бы ничего, что C++ 30 лет развивался эволюционным путем и Rust создавался, в том числе и с учетом всего этого опыта?

Тут диалектика целая. C++ противоречив. Может быть, да наверняка, C++ еще будет долго жить, невзирая на свои недостатки, именно по тому, что до хренища кода на нем написано за всю долгую эволюцию языка, а еще сколько будет написано! Вот, я и сомневаюсь, выживет ли rust в борьбе с таким сильным конкурентом.

Сравнивали бы Rust с его ровесниками (хотя бы относительными), типа Ceylon, Kotlin, Go.

У rust нет сборщика мусора. Это определяющее для меня свойство языка. Поэтому ни kotlin, ни go не подходят для сравнения. Разного поля ягоды. Про ceylon не в курсе.

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