Презентация «Rust - лучше, чем C++» на русском языке от разработчика из Яндекса

Одна крайность не многим лучше другой.

Уже который раз думаю, а не начать ли всерьёз вникать в rust, но после первых нескольких глав в документации возникает ощущение, как в rust'е всё до предела усложнено. И в который раз прихожу к выводу что rust «ненужен».

... возникает ощущение, как в rust'е всё до предела усложнено ...

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

Ты уверен, что это не просто непривычность или чего-то подобное? Можно пример того, что ты находишь бессмысленно усложненным?

Уже который раз думаю, а не начать ли всерьёз вникать в rust, но после первых нескольких глав в документации возникает ощущение, как в rust'е всё до предела усложнено.

Для тех, кому Rust сложен, есть Java, Python, JavaScript... тысячи их.

А когда у этого вашего раста релиз запланирован? Или там еще конца-краю ежемесячным массовым переделкам не видно?

Имеет ли смысл использовать Rust для написания библиотеки? (комментарий)

В презентации, допустим, сразу бросаются в глаза такие вещи:

* параметры передаются в функции как не по-ссылке или значению, а как перемещаются, и нужно явно писать clone (а как сделать по-ссылке?),

* несколько типов строк,

* явные преобразования из одного типа в другой повсеместно.

Даже в С++ всё делается проще. Зачем тогда этот rust, если уже есть С++.

В Rust"std:: писать не надо, т.к. по умолчанию весь std проимпортирован". Почему так?

Я уже давно смотрел, лениво ради этой фразы все видео пересматривать) Там правда так сказано? Если да, то фигово. По умолчанию не «весь std проимпортирован», а добавляется extern crate std; к каждому крейту и use std::prelude::*; к каждому модулю. Т.е. импортируется только prelude.rs - он заметно меньше всего std.

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

Если нужно, то отключить связывание с std можно атрибутом крейта #![no_std], а отключить импорт содержимого prelude - атрибутом модуля #![no_implicit_prelude].

параметры передаются в функции как не по-ссылке или значению, а как перемещаются, и нужно явно писать clone (а как сделать по-ссылке?)

Элементарные типы (числа и не владеющие ссылки) вполне себе копируются. Вот, например: https://www.zerobin.net/?f2bfaad02a260b2f#H4WXPX9ryED1XXcDxkjJf85MDOOu/iadAS/... (да, строки обычно передаются как &str).

несколько типов строк,

Ну надо же как-то отличать строки на стеке от строк в куче? Но имена типов пока неконсистентны, здесь согласен.

явные преобразования из одного типа в другой повсеместно

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

* параметры передаются в функции как не по-ссылке или значению, а как перемещаются, и нужно явно писать clone ...

Допустим, вот: http://doc.rust-lang.org/rust.html#moved-and-copied-types.

Как я понимаю, все относительно просто:

Для типов, которые рекурсивно не имеют деструкторов, не хранят в себе владеющие указатели и т.п. (POD`ы, в общем) компилятор выводит трейт http://doc.rust-lang.org/core/kinds/trait.Copy.htmlCopy и они передаются по значению, простым копированием.

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

Ну и если тебе все-таки надо скопировать такой перемещаемый тип - ты можешь реализовать для него трейт http://doc.rust-lang.org/core/clone/trait.Clone.htmlClone с явным методом clone. Необходимость явного вызова обусловлена общим дизайном языка: чем дешевле что-то в плане производительности, тем больше синтаксической поддержки оно получает и наоборот.

... а как сделать по-ссылке?

Используя '&T' (или '&mut T', если нужна изменяемость).

http://doc.rust-lang.org/guide-pointers.html

* несколько типов строк,

&(mut) str - срез utf-8 строки, которая хранится не важно где, а std::String - стандартный тип, который как раз и владеет строкой и может менять ее размер.

Это особенность, обусловленная низкоуровневостью - тут не питон же все-таки.

В том же C++ есть std::string_view и std::string (и еще const char* более чем часто используется, если строчку не надо менять).

Ну и вот краткое руководство по строкам и свежая тема в реддите «Confused by the purpose of str and String».

* явные преобразования из одного типа в другой повсеместно.

Вроде ж как неявные преобразования типов давно считаются плохой идеей. Например, из faq того же Go: http://golang.org/doc/faq#conversions.

Даже в С++ всё делается проще. Зачем тогда этот rust, если уже есть С++.

Насколько я знаю, в плюсах все или не проще или проще, но далеко не так безопасно.

...Но имена типов пока неконсистентны, здесь согласен...

В смысле что переименовать &str/&mut str в str_slice или вроде того?

В смысле, что статические строки и необладающие ссылки — 'static str и &str, но строка в куче, внезапно, String.

Раньше для этого был просто тип ~str. Потом все '~' убили и функционал перенесли в тип StrBuf, название которого всех раздражало. https://github.com/rust-lang/rfcs/pull/60 - вот RFC по переименованию этого дела в String и его обсуждение, которое я помру все прочитать.

Против варианта Str я, пролистав по диагонали, увидел только вот что:

• str/String is evocative of relationships like simple/complex, light/heavy, small/big. You won't be able to confuse them. &str/Str is problematic because they differ only in the case of one letter; telling them apart is harder than it needs to be.

• I think Str/str would induce a «throw sigils at it»-like situation, where people end up just trying all permutations of Str, &Str and str etc until the compiler stops complaining, and lead to people using &Str when they really should be using &str (this would be «just a bug» in the code they're writing, but choosing Str vs. str is hostile to avoiding such bugs).

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

А на чём пишешь?

Потому что если с С сравнивать, то там и возможностей (высокоуровневых) меньше.

Если с С++, то на мой взгляд, во многих местах наоборот на расте проще. Разве что может быть непривычно. И это при том, что мой основной инструмент - как раз С++ и про раст (пока?) не могу сказать, что он мне целиком нравится.

Если «обилие фич» сравнивать, то опять же, в С++ уже много всякого и дальше хотят добавить всякого (концепты, рефлексию и т.д.). С# тоже на месте не стоит. Про Скалу и не говорю.

Ну и про «непривычность» можно сказать. За всех говорить не буду, но мне (подозреваю, что среднему «императивному» кодеру тоже) разобраться в хаскеле было куда сложнее.

В общем, язык как язык. Не исключаю, что какой-нибудь питон проще для восприятия, но у них и ниши несколько разные. Тем более, что у раста, в отличии от D (имхо) и килерфича есть, а не просто набор «мелких улучшений».

Даже в С++ всё делается проще.

Ты уверен?

несколько типов строк,

Насчёт строк - char, wchar_t, char16_t, char32_t, std::string, std::wstring, std::u16string, std::u32string. И всё это многообразие ещё и не покрывает все ситуации. Поэтому появляются вещи типа QString, CString и т.д.

* параметры передаются в функции как не по-ссылке или значению, а как перемещаются, и нужно явно писать clone (а как сделать по-ссылке?),

Можно подумать в С++ перемещения нет. А уж если сюда заглянуть...

* явные преобразования из одного типа в другой повсеместно.

Явные - это как раз хорошо.

килерфича есть

Это какая же?

Насчёт строк - char, wchar_t, char16_t, char32_t, std::string, std::wstring, std::u16string, std::u32string. И всё это многообразие ещё и не покрывает все ситуации. Поэтому появляются вещи типа QString, CString и т.д.

Ну так то библиотеки. Стандартная строка в C++ одна, std::basic_string - остальное, что ты привел из std:: - ее инстансы. char'ы разные - это просто разные размеры символов. В Rust же ситуация другая и все на ровном месте.

Можно подумать в С++ перемещения нет.

В C++ есть выбор

А уж если сюда заглянуть...

Ну так хорошо же. И совместимость сохранили и новые фичи добавили.

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

А вот в Java, например, на котором тоже пишу, все как-то криво добавляют...

В Rust же ситуация другая и все на ровном месте.

Почему на ровном месте-то? &str — не может расти, может указывать на стек и является необладающей ссылкой. String — строка в куче, может расти и является обладающей ссылкой.
Здесь прямая аналогия между срезом и вектором, это разные типы.

Чем первый случай отличается от массива символов?

http://www.reddit.com/r/rust/comments/2bpenl/confused_by_the_purpose_of_str_a...

&str is a wrapper around &[u8] guaranteeing valid UTF-8 and String is a wrapper around Vec<u8> with the same guarantee. They exist for the same reason there's a distinction between slices and vectors.

Это какая же?

Контроль за «жизнью» указателей на этапе компиляции. Особенно забавно это на фоне D, где ключевое слово scope объявили устаревшим (deprecated) и небезопасным.

остальное, что ты привел из std:: - ее инстансы.

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

Может я не слишком удачно аргументировал, но удобной (из коробки) в С++ работу со строками не назовёшь. Ну и раст же ещё не «зарелизился» - именования, наверняка, подправят и станет более очевидно/удобно.

... именования, наверняка, подправят ...

Презентация «Rust - лучше, чем C++» на русском языке от разработчика из Яндекса (комментарий)

Маловероятно. Разве что будет какой-то пересмотр в связи с введением HKT или подобное.

В C++ есть выбор

Дык, в расте тоже есть выбор, разве нет? Можно скопировать, можно «передать». Точно так же, как и в С++. Тем более, что в расте оперируют (почти?) теми же терминами.

Ну так хорошо же.

Ага, настолько хорошо, что я сомневаюсь в способности среднего программиста на С++ сходу ответить что такое glvalue/prvalue/xvalue. Впрочем, применять это всё действительно не так уж сложно.

В новый C++ все добавлено органично, ничего не сломано, смотрится в духе C++ и разумно.

Я тоже рад развитию (хотя кое-что хотелось бы побыстрее). Но из-за совместимости (да, прекрасно понимаю, что её терять нельзя) в С++ многие фичи выглядят более громоздко. В расте могут себе позволить поэкспериментировать и родить в итоге более приятный синтакс и более совершенные решения. И по сложности тоже должен получиться выигрыш. Скажем, если добавят в С++ модули, то наверняка будут нюансы в их сочетании с легаси-кодом. Или тем более, макросы - ведь сишные выкинуть нельзя, можно только рядом добавить «нормальные».

Чем грузины