Язык программирования Rust стал любимцем разработчиков. Каков статус языка Rust в данный момент? Уроки по языку программирования rust

Rust развивается стабильно, новые возможности и исправления вводятся с каждым релизом раз в 6 недель. Замеченные баги тоже исправляются оперативно в нерегулярных минорных релизах. Иногда такая динамика развития даже может служить препятствием: многие "живые" библиотеки требуют новой версии компилятора, но не всякая компания способна быстро обновлять его на своих проектах.

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

Какого-то единого сборника лучших практик использования Rust, насколько я знаю, пока нет. Много полезных советов есть в официальной документации (в так называемых Книгах), а также разбросано по разным отдельным статьям. Однако, существуют списки полезных статей, которые помогут найти среди них нужную. Например эти:
https://github.com/ctjhoa/rust-learning
https://github.com/brson/rust-anthology/blob/maste...

В новых проектах Rust используется, и пока тенденция идет на расширение. Вот на этой странице вы можете посмотреть, какие компании используют Rust сейчас и для чего: https://www.rust-lang.org/en-US/friends.html

Итак, если вы планируете использовать Rust в производстве, готовьтесь вот к чему:

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

Но что вы получите от использования Rust?

Высокую производительность программ, автоматическое управление памятью без сборщика мусора.
Высокую надежность и защищенность программ, устранение большого количества потенциальных проблем на этапе компиляции.
Достаточно легкий и безопасный процесс рефакторинга и доработки программ, благодаря развитой системе типов.
Развитую систему управления зависимостями проекта.
Действительно хороший универсальный инструмент: Rust подойдет и для прототипирования, и для разработки, причем для любого типа программ (утилиты, настольные приложения, веб-приложения, мобильные приложения, встраиваемые системы). Хорошая поддержка пока еще есть не для всего, но на перспективу - это большой плюс.

Уже сейчас вы могли обратить внимание на то, что синтаксис рассматриваемого языка программирования очень похож на синтаксис таких языков, как C/C++, ведь в обоих случаях для выделения комментариев используются два слэша, блоки кода обрамляются фигурными скобками, а аргументы функций - круглыми скобками. Также следует помнить о том, что для объявления функций используется ключевое слово fn , причем каждая программа должна иметь функцию main() . Восклицательный знак после имени функции println в данном случае указывает на то, что используется макрос (по сути, это удобная обертка над функцией print из библиотеки времени исполнения Rust).

Для компиляции программы следует просто выполнить команду:

Rustc hello.rs

В результате в директории с файлом исходного кода программы должен появиться бинарный файл с именем hello , для исполнения которого достаточно выполнить команду./hello . Но если вы обратите внимание на размер этого файла, вы будете в некоторой степени шокированы: он будет превышать 800 КБ. И все это нужно для работы такой простой программы? Ну, по умолчанию компилятор Rust осуществляет статическое связывание большей части библиотек времени исполнения с программой, поэтому вы можете скопировать бинарный файл в систему, в которой не установлено библиотек времени исполнения Rust и запустить его без каких-либо проблем. Однако, вы также можете сообщить компилятору о необходимости выполнения оптимизаций и динамического связывания:

Rustc -O C prefer-dynamic hello.rs

Теперь вы получите бинарный файл более приемлемого размера, равного 8 КБ, но в случае использования утилиты ldd вы обнаружите, что для корректной работы программы требуется наличие в системе динамической библиотеки libstd-<версия>.so .

Синтаксис языка программирования

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

Fn doubler (x: i32) -> i32 { x * 2 } fn main () { let a: i32 = 5; let b; b = doubler(a); println!("a, умноженное на 2 {}", b); match b { 1 ... 10 => println!("От 1 до 10"), _ => println!("Другое число"), } }

Если вы привыкли работать с языками C/C++, вы можете подумать, что данный код является каким-то странным, но он вполне логичен. Давайте начнем рассмотрение с функции main() : в первой строке let мы объявляем 32-битную целочисленную переменную a и присваиваем ей начальное значение 5. Мы могли бы пропустить указание типа переменной (i32 является стандартным типом переменных), а также не присваивать ей начальное значение, причем в этом случае она содержала бы нулевое значение. Обратите внимание на то, что при объявлении переменной и присваивании ей определенного значения таким же образом, как в случае переменной a из примера, вы не сможете впоследствии изменить ее значение, поэтому при компиляции следующего фрагмента кода будет сгенерировано сообщение об ошибке:

Let a: i32 = 5; a = 10;

По умолчанию переменные в Rust являются неизменяемыми, то есть, их значения не могут изменяться после инициализации. Вы должны явно объявлять изменяемые переменные аналогичным образом:

Let mut a: i32 = 5;

Для чего же это нужно? Это ведь лишняя работа, не так ли? Ну, по сути это действительно так, но, с другой стороны, данная особенность языка программирования помогает разрабатывать безопасные программы. Вы должны делать изменяемыми лишь те переменные, значения которых действительно должны изменяться. Rust заставляет вас быть настолько многословным, насколько это необходимо для максимально точного описания принципа работы программы: в строке выше приведено объявление знаковой целочисленной переменной a размером ровно в 32 бита с возможностью изменения ее значения в будущем.

Далее мы вызываем нашу функцию doubler с переменной a в качестве аргумента и сохраняем возвращаемое значение в переменной b . Обратите внимание на объявление функции doubler , которое находится в начале кода программы: в нем указывается тип параметра функции (i32) и тип возвращаемого значения (i32) после символов ->. Также несложно заметить, что в рамках функции выполняется единственная операция x * 2 , после которой даже не следует символа точки с запятой, как в обычном блоке кода на языке Rust; что же происходит там?

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

Вернемся в функцию main() , в которой мы использовали макрос println!() для вывода результата; обратите внимание на методику подстановки значения переменной с помощью последовательности символов {} . Наконец, в примере демонстрируется чрезвычайно полезное ключевое слово "match" языка программирования Rust, которое позволяет значительно сократить объем кода в том случае, если вам необходимо выполнить большое количество операций if/else. В данном случае 1 … 10 является объявлением диапазона значений (от 1 до 10 включительно), а символ подчеркивания (_) соответствует всем остальным значениям.

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

Let x = (1, 2.0, "Hello");

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

Println!("{}", x.2);

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

Fn switch(input: (i32, i32)) -> (i32, i32) { (input.1, input.0) } fn main() { let x = (10, 50); let y = switch(x); println!("{}, {}", y.0, y.1); }

В данном случае функция с именем switch() принимает кортеж с двумя 32-битными целочисленными значениями и сохраняет их в переменной input . При этом она также возвращает кортеж с двумя целочисленными значениями. В рамках данной функции используется простое выражение, позволяющее поменять местами элементы кортежа и вернуть получившийся кортеж.

В рамках функции main() создается кортеж с именем x , содержащий значения 10 и 50, а также кортеж с именем y , содержащий значения, которые были возвращены после вызова функции switch() . Далее осуществляется простой вывод значений кортежа на экран (50, 10).

Совет: Если вам не терпится самостоятельно разобраться с возможностями Rust, рекомендуем начать с чтения официальной документации, расположенной по адресу https://doc.rust-lang.org/book .

Это было краткое описание синтаксиса и возможностей языка программирования Rust; если вы желаете узнать больше о данном языке программирования из специальной серии статей, дайте нам знать об этом!

Rust - новый экспериментальный язык программирования, разрабатываемый Mozilla. Язык компилируемый и мультипарадигмальный, позиционируется как альтернатива С/С++, что уже само по себе интересно, так как даже претендентов на конкуренцию не так уж и много. Можно вспомнить D Вальтера Брайта или Go от Google.
В Rust поддерживаются функицональное, параллельное, процедурное и объектно-ориентированное программирование, т.е. почти весь спектр реально используемых в прикладном программировании парадигм.

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

Первое впечатление

Синтаксис языка строится в традиционном си-подобном стиле (что не может не радовать, так как это уже стандарт де-факто). Естественно, всем известные ошибки дизайна С/С++ учтены.
Традиционный Hello World выглядит так:
use std; fn main(args: ) { std::io::println("hello world from " + args + "!"); }

Пример чуть посложнее - функция расчета факториала:

Fn fac(n: int) -> int { let result = 1, i = 1; while i <= n { result *= i; i += 1; } ret result; }

Как видно из примера, функции объявляются в «функциональном» стиле (такой стиль имеет некоторые преимущества перед традиционным «int fac(int n)»). Видим автоматический вывод типов (ключевое слово let), отсутствие круглых скобок у аргумента while (аналогично Go). Еще сразу бросается в глаза компактность ключевых слов. Создатели Rust дейтсвительно целенаправленно сделали все ключевые слова как можно более короткими, и, скажу честно, мне это нравится.

Мелкие, но интересные синтаксические особенности

В числовые константы можно вставлять подчеркивания. Удобная штука, сейчас эту возможность добавляют во многие новые языки.
0xffff_ffff_ffff_ffff_ffff_ffff
Двоичные константы. Конечно, настоящий программист должен преобразовывать bin в hex в уме, но ведь так удобнее! 0b1111_1111_1001_0000
Тела любых операторов (даже состоящие из единственного выражения) должны быть обязательно заключены в фигурные скобки. К примеру, в Си можно было написать if(x>0) foo(); , в Rust нужно обязательно поставить фигурнные скобки вокруг foo()
Зато аргументы операторов if, while и подобных не нужно заключать в кругные скобки
во многих случаях блоки кода могут рассматриваться как выражения. В частности, возможно например такое:
let x = if the_stars_align() { 4 } else if something_else() { 3 } else { 0 };
синтаксис объявления функций - сначала ключевое слово fn, затем список аргументов, тип аргумента указывается после имени, затем, если функция возвращает значение - стрелочка "->" и тип возвращаемого значения
аналогичным образом объявляются переменные: ключевое слово let, имя переменной, после переменной можно через двоеточие уточнить тип, и затем - присвоить начальное значение.
let count: int = 5;
по умолчанию все переменные неизменяемые; для объявления изменяемых переменных используется ключевое слово mutable.
имена базовых типов - самые компактные из всех, которые мне встречались: i8, i16, i32, i64, u8, u16, u32, u64,f32, f64
как уже было сказано выше, поддерживается автоматический вывод типов

В языке присутствую встроенные средства отладки программ:
Ключевое слово fail завершает текущий процесс
Ключевое слово log выводит любое выражение языка в лог (например, в stderr)
Ключевое слово assert проверяет выражение, и если оно ложно, завершает текущий процесс
Ключевое слово note позволяет вывести дополнительную инфорацию в случае аварийного завершения процесса.

Типы данных

Rust, подобно Go, поддерживает структурную типизацию (хотя, по утверждению авторов, языки развивались независимо, так что это влияние их общих предшественников - Alef, Limbo и т.д.). Что такое структурная типизация? Например, у вас в каком-то файле объявлена структура (или, в терминологии Rust, «запись»)
type point = {x: float, y: float};
Вы можете объявить кучу переменных и функций с типами аргументов «point». Затем, где-нибудь в другом месте, вы можете объявить какую-нибудь другую структуру, например
type MySuperPoint = {x: float, y: float};
и переменные этого типа будут полностью совместимы с переменными типа point.

В противоположность этому, номинативная типизация, принятая в С, С++,C# и Java таких конструкций не допускает. При номинативной типизации каждая структура - это уникальный тип, по умолчанию несовместимый с другими типами.

Структуры в Rust называются «записи» (record). Также имеются кортежи - это те же записи, но с безымянными полями. Элементы кортежа, в отличие от элементов записи, не могут быть изменяемыми.

Имеются вектора - в чем-то подобные обычным массивам, а в чем-то - типу std::vector из stl. При инициализации списком используются квадратные скобки, а не фигурные как в С/С++

Let myvec = ;

Вектор, тем ни менее - динамическая структура данных, в частности, вектора поддерживают конкатенацию.

Let v: mutable = ; v += ;

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

Fn for_rev(v: [T], act: block(T)) { let i = std::vec::len(v); while i > 0u { i -= 1u; act(v[i]); } } type circular_buf = {start: uint, end: uint, buf: };

Язык поддерживает так называемые теги . Это не что иное, как union из Си, с дополнительным полем - кодом используемого варианта (то есть нечто общее между объединением и перечислением). Или, с точки зрения теории - алгебраический тип данных.

Tag shape { circle(point, float); rectangle(point, point); }

В простейшем случае тег идентичен перечислению:

Tag animal { dog; cat; } let a: animal = dog; a = cat;
В более сложных случаях каждый элемент «перечисления» - самостоятельная структура, имеющая свой «конструктор».
Еще интересный пример - рекурсивная структура, с помощью которой задается объект типа «список»:
tag list { nil; cons(T, @list); } let a: list = cons(10, @cons(12, @nil));
Теги могут участвовать в выражениях сопоставления с образцом, которые могут быть достаточно сложными.
alt x { cons(a, @cons(b, _)) { process_pair(a,b); } cons(10, _) { process_ten(); } _ { fail; } }

Сопоставление с образцом (pattern matching)

Для начала можно рассматривать паттерн матчинг как улучшенный switch. Используется ключевое слово alt, после которого следует анализируемое выражение, а затем в теле оператора - паттерны и действия в случае совпадения с паттернами.
alt my_number { 0 { std::io::println("zero"); } 1 | 2 { std::io::println("one or two"); } 3 to 10 { std::io::println("three to ten"); } _ { std::io::println("something else"); } }
В качестве «паттеронов» можно использовать не только константы (как в Си), но и более сложные выражения - переменные, кортежи, диапазоны, типы, символы-заполнители (placeholders, "_"). Можно прописывать дополнительные условия с помощью оператора when, следующего сразу за паттерном. Существует специальный вариант оператора для матчинга типов. Такое возможно, поскольку в языке присутствует универсальный вариантный тип any , объекты которого могут содержать значения любого типа.

Указатели. Кроме обычных «сишных» указателей, в Rust поддерживаются специальные «умные» указатели со встроенным подсчетом ссылок - разделяемые (Shared boxes) и уникальные (Unique boxes). Они в чем-то подобны shared_ptr и unique_ptr из С++. Они имеют свой синтаксис: @ для разделяемых и ~ для уникальных. Для уникальных указателей вместо копирования существует специальная операция - перемещение:
let x = ~10; let y <- x;
после такого перемещения указатель x деинициализируется.

Замыкания, частичное применение, итераторы

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

1. Ключевое слово lambda используется для объявления вложенной функции или функционального типа данных.

Fn make_plus_function(x: int) -> lambda(int) -> int { lambda(y: int) -> int { x + y } } let plus_two = make_plus_function(2); assert plus_two(3) == 5;

В этом примере мы имеем функцию make_plus_function, принимающую один аргумент «x» типа int и возвращающую функцию типа «int->int» (здесь lambda - ключевое слово). В теле функции описывается эта самая фунция. Немного сбивает с толку отсутствие оператора «return», впрочем, для ФП это обычное дело.

2. Ключевое слово block используется для объявления функционального типа - аргумента функции, в качестве которого можно подставить нечто, похожее на блок обычного кода.
fn map_int(f: block(int) -> int, vec: ) -> { let result = ; for i in vec { result += ; } ret result; } map_int({|x| x + 1 }, );

Здесь мы имеем функцию, на вход которой подается блок - по сути лямбда-функция типа «int->int», и вектор типа int (о синтаксисе векторов далее). Сам «блок» в вызывающем коде записыавется с помощью несколько необычного синтаксиса {|x| x + 1 }. Лично мне больше нравятся лямбды в C#, символ | упорно воспринимается как битовое ИЛИ (которое, кстати, в Rust также есть, как и все старые добные сишные операции).

3. Частичное применение - это создание функции на основе другой функции с большим количеством аргументов путем указания значений некоторых аргументов этой другой функции. Для этого используется ключевое слово bind и символ-заполнитель "_":

Let daynum = bind std::vec::position(_, ["mo", "tu", "we", "do", "fr", "sa", "su"])

Чтобы было понятнее, скажу сразу, что такое можно сделать на обычном Си путем создания простейшей обертки, как-то так:
const char* daynum (int i) { const char *s ={"mo", "tu", "we", "do", "fr", "sa", "su"}; return s[i]; }

Но частичное применение - это функциональный стиль, а не процедурный (кстати, из приведенного примера неясно, как сделать частичное применение, чтобы получить функцию без аргументов)

Еще пример: объявляется функция add с двумя аргументами int, возвращающая int. Далее объявляется функциональный тип single_param_fn, имеющий один аргумент int и возвращающий int. С помощью bind объявляются два функциональных объекта add4 и add5, построенные на основе функции add, у которой частично заданы аргументы.

Fn add(x: int, y: int) -> int { ret x + y; } type single_param_fn = fn(int) -> int; let add4: single_param_fn = bind add(4, _); let add5: single_param_fn = bind add(_, 5);

Функциональные объекты можно вызывать также, как и обычные функции.
assert (add(4,5) == add4(5)); assert (add(4,5) == add5(4));

4. Чистые функции и предикаты
Чистые (pure) функции - это функции, не имеющие побочных эффектов (в том числе не вызывающие никаких других функций, кроме чистых). Такие функции выдяляются ключевым словом pure.
pure fn lt_42(x: int) -> bool { ret (x < 42); }
Предикаты - это чистые (pure) функции, возвращающие тип bool. Такие функции могут использоваться в системе typestate (см. дальше), то есть вызываться на этапе компиляции для различных статических проверок.

Синтаксические макросы
Планируемая фича, но очень полезная. В Rust она пока на стадии начальной разработки.
std::io::println(#fmt("%s is %d", "the answer", 42));
Выражение, аналогичное сишному printf, но выполняющееся во время компиляции (соответственно, все ошибки аргументов выявляются на стадии компиляции). К сожалению, материалов по синтаксическим макросам крайне мало, да и сами они находятся в стадии разработки, но есть надежда что получится что-то типа макросов Nemerle .
Кстати, в отличие от того же Nemerle, решение выделить макросы синтаксически с помощью символа # считаю очень грамотным: макрос - это сущность, очень сильно отличающаяся от функции, и я считаю важным с первого взгляда видеть, где в коде вызываются функции, а где - макросы.

Атрибуты

Концепция, похожая на атрибуты C# (и даже со схожим синтаксисом). За это разработчикам отдельное спасибо. Как и следовало ожидать, атрибуты добавляют метаинформацию к той сущности, которую они аннотируют,
# fn register_win_service() { /* ... */ }
Придуман еще один вариант синтаксиса атрибутов - та же строка, но с точкой с запятой в конце, аннотирует текущий контекст. То есть то, что соответствует ближайшим фигурным скобкам, охватывающим такой атрибут.
fn register_win_service() { #; /* ... */ }

Параллельные вычисления

Пожалуй, одна из наиблее интересных частей языка. При этом в tutorial на данный момент не описана вообще:)
Программа на Rust состоит из «дерева задач». Каждая задача имеет функцию входа, собственный стек, средства взаимодействия с другими задачами - каналы для исходящей информации и порты для входящей, и владеет некоторой частью объектов в динамической куче.
Множество задач Rust могут существовать в рамках одного процесса операционной системы. Задачи Rust «легковесные»: каждая задача потребляет меньше памяти чем процесс ОС, и переключение между ними осуществляется быстрее чем переключение между процессами ОС (тут, вероятно, имеются в виду все-же «потоки»).

Задача состоит как минимум из одной функции без аргументов. Запуск задачи осуществляется с помощью функции spawn. Каждая задача может иметь каналы, с помощью которых она передает инфорацию другим задачам. Канал - это специальный шаблонный тип chan, параметризируемый типом данных канала. Например, chan - канал для передачи беззнаковых байтов.
Для передачи в канал используется функция send, первым аргументом которой является канал, а вторым - значение для передачи. Фактически эта функция помещает значение во внутренний буфер канала.
Для приема данных используются порты. Порт - это шаблонный тип port, параметризируемый типом данных порта: port - порт для приема беззнаковых байтов.
Для чтения из портов используется функция recv, аргументом которой является порт, а возвращаемым значением - данные из порта. Чтение блокирует задачу, т.е. если порт пуст, задача переходит в состояние ожидания до тех пор, пока другая задача не отправит на связанный с портом канал данные.
Связывание каналов с портами происходит очень просто - путем инициализации канала портом с помощью ключевого слова chan:
let reqport = port();
let reqchan = chan(reqport);
Несколько каналов могут быть подключены к одному порту, но не наоборот - один канал не может быть подключен одновременно к нескольким портам.

Typestate

Общепринятого перевода на русский понятия «typestate» я так и не нашел, поэтому буду называть это «состояния типов». Суть этой фичи в том, что кроме обычного контроля типов, принятого в статической типизации, возможны дополнительные контекстные проверки на этапе компиляции.
В том или ином виде состояния типов знакомы всем программистам - по сообщениям компилятора «переменная используется без инициализации». Компилятор определяет места, где переменная, в которую ни разу не было записи, используется для чтения, и выдает предупреждение. В более общем виде эта идея выглядит так: у каждого объекта есть набор состояний, которые он может принимать. В каждом состоянии для этого объекта определены допустимые и недопустимые операции. И компилятор может выполнять проверки - допустима ли конкретная операция над объектом в том или ином месте программы. Важно, что эти проверки выполняются на этапе компиляции.

Например, если у нас есть объект типа «файл», то у него может быть состояние «закрыт» и «открыт». И операция чтения из файла недопустима, если файл закрыт. В современных языках обычно функция чтения или бросает исключение, или возвращает код ошибки. Система состояний типов могла бы выявить такую ошибку на этапе компиляции - подобно тому, как компилятор определяет, что операция чтения переменной происходит до любой возможной операции записи, он мог бы определить, что метод «Read», допустимый в состоянии «файл открыт», вызывается до метода «Open», переводящего объект в это состояние.

В Rust существует понятие «предикаты» - специальные функции, не имеющие побочных эффектов и возвращающие тип bool. Такие функции могут использоваться компилятором для вызова на этапе компиляции с целью статических проверок тех или иных условий.

Ограничения (constraints) - это специальные проверки, которые могут выполняться на этапе компиляции. Для этого используется ключевое слово check.
pure fn is_less_than(int a, int b) -< bool { ret a < b; } fn test() { let x: int = 10; let y: int = 20; check is_less_than(x,y); }
Предикаты могут «навешиваться» на входные параметры функций таким вот способом:
fn test(int x, int y) : is_less_than(x,y) { ... }

Информации по typestate крайне мало, так что многие моменты пока непонятны, но концепция в любом случае интересная.

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

Перевод статьи Федерико Мена-Кинтеро, который, наряду с Мигелем де Икаса, основал проект GNOME - широко используемую, свободную графическую среду, в основном для систем GNU/Linux. Перед этим он некоторое время поддерживал GIMP . Сейчас Федерико активно развивает библиотеку librsvg с использованием языка программирования Rust. По его мнению, разработка достигла момента, когда портирование некоторых крупных компонент с C на Rust выглядит более лёгкой задачей, чем просто добавление аксессоров к ним. Федерико часто приходится переключаться с C на Rust и обратно, и в статье он рассказывает, почему считает C очень и очень примитивным языком для современного ПО.

Своего рода элегия по C

Я влюбился в язык программирования C около 24-ёх лет назад. Я выучил основы, прочитав испанский перевод второго издания «Языка программирования C» Кернигана/Ритчи (K&R) . До этого я писал на Turbo Pascal в довольно низкоуровневой манере - с указателями и ручным выделением памяти. После него C казался освежающим и мощным.

К&R - это отличная книга благодаря стилю изложения и лаконичности программирования. Эта книга даже учит, как реализовать простые функции malloc/free , что крайне поучительно. Даже такие низкоуровневые конструкции, которые выглядят как часть языка, могут быть реализованы на самом языке!

В последующие годы я хорошо освоил C. Это простой язык с небольшой стандартной библиотекой. Наверное, это был идеальный язык для реализации ядер Unix в 20 000 строк кода или около того.

GIMP и GTK+ научили меня тому, как использовать модный объектно-ориентированный подход в C. GNOME показал, как поддерживать крупномасштабные проекты, написанные на C. Стало казаться, что 20 000 строк C кода - это проект, который можно практически полностью понять за пару недель.

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

Опыт использования C

Положительный

Чтение исходного кода проекта POV-Ray впервые и изучение того, как использовать объектно-ориентированный подход и наследование в чистом C;
Чтение исходного кода проекта GTK+ и изучение читаемого, поддерживаемого и чистого стиля написания кода на C;
Чтение исходного кода проекта SIOD, а также ранних исходников проекта Guile и понимание того, как интерпретатор Scheme может быть написан на C;
Написание первых версий Eye of Gnome и доработка системы микротайлового рендеринга.

Негативный

Работа в команде Evolution, когда программа постоянно падала. Мы были вынуждены приобрести машину с Solaris на борту, чтобы иметь возможность купить Purify; в те времена Valgrind-а еще не существовало;
Отладка взаимных блокировок потоков в gnome-vfs;
Безуспешная отладка Mesa;
Когда мне передали исходники первых версий Nautilus-share, я увидел, что free() вообще не используется;
Попытки рефакторинга кода, о стратегии управления памятью которого я не имел понятия;
Попытка сделать библиотеку из кода, кишащего глобальными переменными, и в котором ни одна функция не помечена как static .

Фичи Rust, которых не хватает в C

Автоматическое управление ресурсами

Один из первых блог-постов, которые я прочитал о Rust, назывался «В Rust вам никогда не придётся закрывать сокет» . Rust заимствует у C++ идеи об идиоме (Resource Acquisition Is Initialization, получение ресурса есть инициализация) и умных указателях, добавляет принцип единоличного владения для значений и предоставляет механизм автоматического, детерминированного управления ресурсами в очень изящной упаковке.

Автоматическое: не нужно вызывать free() вручную. Память освободится, файлы закроются, мьютексы разблокируются, когда переменные выйдут из зоны видимости. Если вам нужно написать обёртку для стороннего ресурса, то всё, что нужно сделать, это реализовать типаж Drop. Обёрнутый ресурс ощущается как часть языка, потому что вам не приходится нянчиться с его временем жизни вручную;
Детерминированное: ресурсы создаются (память выделяется и инициализируется, файлы открываются и т. д.) и уничтожаются, когда выходят из зоны видимости. Никакой сборки мусора: ресурсы действительно освобождаются, когда вы закрываете скобку. Вы начинаете видеть время жизни данных в своей программе как дерево вызовов функций.

После того, как постоянно забываешь освобождать/закрывать/уничтожать объекты в C, или, ещё хуже, пытаешься понять, где в чужом коде забыли сделать что-то из этого (или ошибочно сделали дважды )… я просто больше этого не хочу.

Дженерики

Vec - это действительно вектор, размер элементов которого равен размеру объекта типа T . Это не массив указателей на объекты, память для которых выделялась отдельно. Он специально компилируется в код, который может работать только с объектами типа T .

После написания большого количества сомнительных макросов на C, чтобы сделать что-то похожее… я больше этого не хочу.

Типажи - это больше, чем просто интерфейсы

Rust - это не Java-подобный объектно-ориентированный язык, подробнее об этом можно прочитать в open-source книге «The Rust Programming Language» . Вместо этого в нём есть типажи, которые поначалу похожи на интерфейсы в Java, - простой способ осуществления динамического переключения (dynamic dispatch), так что если объект реализует Drawable , то можно предположить, что у него есть метод draw() .

Однако типажи - это более мощный инструмент. Одной из отличительных особенностей типажей можно считать ассоциированные типы (associated types). Например, Rust предоставляет типаж Iterator , который вы можете реализовать:

Pub trait Iterator { type Item; fn next(&mut self) -> Option; }

Это означает, что всякий раз, когда вы реализуете этот типаж для какого-либо объекта, поддерживающего итерирование, вы также указываете тип Item для значений, которые он выдаёт. Если вы вызываете next() и элементы ещё остались, вы получите Some(ТипВашегоЭлемента) . Когда у вашего итератора закончатся элементы, он вернет None .

Ассоциированные типы могут ссылаться на другие типажи.

Например, в Rust вы можете использовать циклы for со всем, что реализует типаж IntoIterator:

Pub trait IntoIterator { /// Тип элементов, по которым идёт итерация type Item; /// В какой тип итератора мы преобразуемся? type IntoIter: Iterator; fn into_iter(self) -> Self::IntoIter; }

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

Таким образом, вы можете построить настоящую сеть типов, которые ссылаются друг на друга. Вы можете написать типаж, который говорит: «Я могу сделать foo и bar, но только если вы дадите мне тип, который умеет делать вот это и это».

Срезы

Я уже писал о том, насколько в C не хватает срезов (slices) для работы со строками и какая это головная боль, когда привык, что они под рукой.

Современные инструменты для управления зависимостями

Вместо того, чтобы

Запускать pkg-config руками или через Autotools-макрос;
Сражаться с include-путями в заголовочных файлах…
… и библиотечных файлах;
И, по сути, полагаться на то, что пользователь гарантирует установку верных версий библиотек,

вы пишете файл Cargo.toml , в котором перечисляются названия и версии всех наших зависимостей. Они будут загружены из общеизвестного источника или из любого другого, указанного вами.

Не нужно сражаться с зависимостями. Оно просто работает, когда вы набираете cargo build .

Тесты

В C очень сложно покрывать код тестами по нескольким причинам:

Внутренние функции часто помечены как static . Это означает, что они не могут быть вызваны вне файла, в котором эта функция определена. Тестовая программа вынуждена либо #include -ить содержимое исходника, в котором функция объявлена, либо использовать #ifdef , чтобы убирать static только при тестировании;
Вам придётся плясать с бубном вокруг вашего Makefile, чтобы слинковать тестовую программу с определённой частью зависимостей основной или с какой-то частью оставшейся программы;
Вам придётся выбрать фреймворк для тестирования. Вам придётся зарегистрировать свои тесты в фреймворке для тестирования. Вам придётся изучить этот фреймворк.

В Rust вы пишете

# fn test_that_foo_works() { assert!(foo() == expected_result); }

в любом месте программы или библиотеки, и, когда вы набираете cargo test , ОНО ПРОСТО, *****, РАБОТАЕТ. Этот код линкуется только в тестовый исполняемый файл. Не нужно ничего компилировать дважды вручную, писать Makefile-магию или разбираться, как вытащить внутренние функции для тестирования.

Для меня это одна из главных киллер-фич языка.

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

Rust генерирует документацию на основе комментариев, размеченных с помощью Markdown. Код из документации запускается как обычные тесты . Вы можете показывать, как функция должна использоваться, одновременно тестируя её:

/// Multiples the specified number by two /// /// ``` /// assert_eq!(multiply_by_two(5), 10); /// ``` fn multiply_by_two(x: i32) -> i32 { x * 2 }

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

Гигиеничные макросы

В Rust особые гигиеничные макросы, позволяющие избежать проблем, при которых во время разворачивания C макросов происходит непреднамеренное затенение идентификаторов в коде. Вам больше не нужно писать макросы, заключая все символы в скобки, чтобы max(5 + 3, 4) работал правильно.

Никакого неявного приведения типов

Все эти баги, которые появляются в C из-за непреднамеренного приведения int к short или к char и т. п. - в Rust их нет. Вы должны приводить типы явно.

Никакого целочисленного переполнения

Этим всё сказано.

Как правило, никакого неопределённого поведения в безопасном режиме

В Rust, если что-то вызывает неопределенное поведение в «безопасном режиме» (всё, что написано вне блоков unsafe {}), это расценивается как баг самого языка. Например, можно сделать побитовый сдвиг отрицательного целого числа вправо и произойдёт именно то, что вы ожидаете.

Сопоставление с образцом

Знаете, как gcc выдает предупреждение, если вы используете switch() с перечислением (enum), но обработаете не все варианты? Это детский сад по сравнению с Rust.

В Rust в различных местах используется сопоставление с образцом . Он умеет делать эту штуку с перечислениями в match-выражении. Он поддерживает деструктурирование, а это значит, что можно возвращать несколько значений из функции:

Impl f64 { pub fn sin_cos(self) -> (f64, f64); } let angle: f64 = 42.0; let (sin_angle, cos_angle) = angle.sin_cos();

match работает на строках. ВЫ МОЖЕТЕ МАТЧИТЬ ГРЁБАНЫЕ СТРОКИ.

Let color = "зеленый"; match color { "красный" => println!("Это красный"), "зеленый" => println!("Это зеленый"), _ => println!("Что-то другое"), }

Вы же знаете, насколько такое плохо читается?

my_func(true, false, false)

Как насчет того, чтобы вместо этого использовать сопоставление с образцом на аргументах функции:

Pub struct Fubarize(pub bool); pub struct Frobnify(pub bool); pub struct Bazificate(pub bool); fn my_func(Fubarize(fub): Fubarize, Frobnify(frob): Frobnify, Bazificate(baz): Bazificate) { if fub { ...; } if frob && baz { ...; } } ... my_func(Fubarize(true), Frobnify(false), Bazificate(true));

Стандартная полезная обработка ошибок

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

#

Если вы пишете новый тип (скажем, структуру с кучей полей), то можно написать # , и Rust будет знать, как автоматически напечатать содержимое этого типа для отладки. Больше не нужно руками писать специальную функцию, которую затем придётся вызывать из gdb, только для того, чтобы посмотреть содержимое полей пользовательского типа.

Замыкания

Вам больше не придётся передавать указатели на функцию и user_data вручную.

Заключение

Я пока не попробовал «fearless concurrency» , где компилятор может предотвращать гонки данных в многопоточном коде. Я полагаю, что это в корне меняет положение дел для людей, которые пишут параллельный код на регулярной основе.

C - это старый язык с примитивными конструкциями и примитивными инструментами. Он хорошо подходил для небольших однопроцессорных Unix-ядер, которые работали в доверенных, академических средах. Но для современного программного обеспечения он больше не подходит.

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

Нам очень понравилась статья "Критика языка Rust и почему C/C++ никогда не умрет". Мы предложили автору, что выполним перевод статьи на английский язык, а также опубликовать её в нашем блоге. Он согласился, и мы с удовольствием представляем эту статью на русском и английском языке. Оригинал статьи находится .

Оригинал статьи размещён (текст на русском языке). Статья опубликована в нашем блоге с соглашения автора.

Примечание : Ниже по тексту я исхожу из предположения, что Rust является попыткой сделать быстрый и безопасный язык. В конце концов, ребята из Mozilla делали его, как инструмент разработки браузерного движка . Если же это очередной просто безопасный язык, тогда получаем странное. Самых разных безопасных языков и так уже пруд пруди, каждый найдет себе по вкусу. И если не стоит цели заменить C++, то (1) для чего в языке сделано unsafe подмножество? (2) зачем было удалять из языка легковесные потоки , удобно же? Другими словами, в этом случае происходящее вообще не имеет никакого смысла.

Если вдруг вы почитываете форум linux.org.ru, отмечу, это это не тот список из 10 чисто технических причин не любить Rust , речь о котором шла в этом трэде . Как показало обсуждение в Skype с уважаемым товарищем @sum3rman , есть больше одного мнения касательно того, насколько "техническими" считать эти причины. В общем, фиговый список я составил, но кое-какие пункты из него, наиболее интересные, пожалуй, я все-таки рискну привести. На самом деле, тут и простых, не технических, причин за глаза хватает.

То, что C/C++ в обозримом будущем никуда не денутся, и так любому трезво мыслящему человеку понятно. Никто не станет переписывать почти все десктопные приложения, ядра операционных систем, компиляторы, игровые и браузерные движки, виртуальные машины, базы данных, архиваторы, аудио- и видеокодеки, тонны прочих сишных библиотек, и так далее. Это очень-очень много быстрого, отлаженного, проверенного временем кода. Переписывать его очень-очень дорого, рискованно, и если честно, не лишено смысла только в искаженном сознании только самых упоротых Rust"оманов. Спрос на C/C++ программистов был и будет велик еще очень долго.

Хорошо, а как на счет применения Rust при написании нового кода?

Вспомним, что это уже далеко не первая попытка сделать "более правильный" C/C++. Возьмем хотя бы язык D. Появился в 2001 году, очень хороший язык. Нет ни вакансий, ни нормальных инструментов разработки, ни каких-то особо выдающихся саксесс сторис. Проект OpenMW изначально писали на D, а потом внезапно решили целиком переписать на C++ . Как признаются разработчики, им приходило много писем в стиле "отличный проект, мы были бы рады в него контрибьютить, но не знаем и не хотим знать этот дурацкий D". Википедия сообщает, что помимо D была и масса других попыток в той или иной степени убить C++, например, Vala , Cyclone, Limbo, BitC. Многие ли вообще слышали о таких языках?

Думаю, давно пора извлечь уроки из истории. Ни один здравомыслящий человек не потащит в проект новый язык, пока вы хотя бы не покажете ему нормальные инструменты разработки, не расскажете парочку саксесс сторис и не покажете десяток программистов на этом языке, живущих поблизости. Программисты же, пожалуй, кроме самых молодых, никогда не станут тратить свое время и здоровье на изучение очередного самого правильного языка, пока вы не покажете им нормальные инструменты разработки (не поделки типа Racer), пару десятков тысяч готовых библиотек (не "experimental", "unstable" и так далее), не расскажете парочку саксесс сторис и не покажите десяток открытых вакансий в их городе. Проблема курицы и яйца. Очень редко эту проблему удается успешно решить (условно тут можно привести в пример и Scala), в основном благодаря вложению времени и денег со стороны некоторой крупной компании (Google, Typesafe), по каким-то своим соображениям заинтересованных в популяризации языка.

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

C/C++ критикуют за разное. Критикуют, кстати, очень часто те, кто в продакшене даже издали не видел кода на С++. Коротко и ясно проблему можно описать так: С++ очень быстрый (а также не требовательный к памяти, заряду батареи и тд), но не безопасный в том смысле, что позволяет выходить за границы массивов, по ошибке обращаться к освобожденным кускам памяти и так далее. В свое время эта проблема привела к появлению массы безопасных языков, таких, как Java, C#, Python и других. Но оказалось, что эти языки по сравнению с C++ слишком требовательны к ресурсам и обладают прочими недостатками, вспомним хотя бы неизбежный stop the world при сборке мусора. Поэтому люди бьются над задачей сделать язык такой же быстрый, как C++, но еще и безопасный. Одним из таких языков и является Rust.

Rust действительно безопасный, но, к сожалению, далеко не быстрый. По скорости на момент написания этих строк Rust сравним с Java, Go и Haskell:

Я искренне надеюсь, что со временем его как-то разгонят, но до тех пор в плане компромисса скорости и безопасности он не намного интереснее Scala или Go. До сих пор остается открытым вопрос, можно ли вообще сделать язык быстрым и безопасным, или постоянные проверки на выход за границы массива, безопасные обвязки вокруг биндингов к сишным библиотекам и так далее автоматически делают любой язык в 2 раза медленнее С/C++.

А за счет чего, собственно, Rust безопасен? Если говорить простыми словами, то это язык со встроенным статическим анализатором кода. Действительно очень крутым статическим анализатором, который ловит все типичные для С++ ошибки, притом не только связанные с управлением памятью, но и многопоточностью . Передал по каналу ссылку на изменяемый объект другому потоку, а потом попробовал воспользоваться этой ссылкой сам - все, не скомпилится. Это действительно здорово.

Часто приводится аргумент, что 90% времени выполняется только 10% кода (что, насколько я понимаю, чисто эмпирическое правило - быстро найти строгих исследований на эту тему не удалось). Следовательно, бОльшую часть программы можно написать на безопасном Rust, а 10% "горячего" кода - на его unsafe подмножестве, и медленность текущей реализации Rust на самом деле не представляет собой проблемы. Ок, но тогда получается, что Rust вообще не нужен, потому что я могу написать 90% кода на Go, а 10% на Си. Только искатели серебряных пуль и оторванные от реальности те-еретики будут использовать Rust исключительно из соображений, что 100% программы можно написать как бы на одном языке. Хотя в действительности это два диалекта одного языка, что не так уж сильно отличается от связки Java плюс Си или Go плюс Си.

На самом деле, правило 10:90 - это все равно вранье. По этой логике можно переписать 90% WebKit, 90% VirtualBox или 90% GCC на Java и получить такой же результат. Очевидно, это не так. Даже если дело не в том, что в ряде программ это отношение очень другое, то следите за руками. Допустим, вся программа написана на небезопасном C/C++ и время ее выполнения, условно говоря, равно 0.9*1 (малая часть горячего кода) + 0.1*1 (много холодного кода) = 1. Теперь сравним с программой на безопасном языке со вставками на Си: 0.9*1 + 0.1*2 = 1.1, условно 10% разницы. Это много или мало? Зависит от ваших масштабов. В случае с Google даже несколько процентов могут сэкономить миллионы долларов (см пункт 5 в пейпере, "Utilization"). Или представьте, что со следующим обновлением JVM внезапно начнет требовать на 10% больше ресурсов! Я боюсь даже гадать, сколько нулей будет в цифре, полученной после перевода процентов на американские деньги! 10% - это дофига в задачах, где используются Си и C++.

Мы повторяем "преждевременная оптимизация - корень всех зол", как мантру. Но если следовать ей буквально, то давайте повсюду использовать пузырьковую сортировку вместо quicksort. Мы же не знаем точно, что программа будет именно в этом месте тормозить! Какой смысл оборачивать обыкновенные счетчики каких-тод ействий в акторы или транзакционную память, если можно сразу воспользоваться более эффективным atomic? И вообще, в тривиальных случаях нет смысла принудительно инициализировать все-все-все переменные, делать кучу дополнительных проверок и так далее. Пусть в итоге мы получим не 10% ускорения, а 2-5%. Это ведь тоже совсем неплохо, если потребовало всего лишь пары лишних минут размышлений. И как мы уже выяснили, в задачах, решаемых на С/C++, это может быть большой разницей! Потом, кто сказал, что найти горячее место, переписать код (возможно, очень много кода) и доказать, что он стал действительно быстрее - это проще, чем подумать о производительности заранее?

Если отвлечься от вопроса компромисса скорости и безопасности, то по дизайну самого языка у меня тоже есть вопросы. В частности, касательно пяти типов указателей. С одной стороны, это неплохо, когда программист задумывается о том, где лежат переменные, в стеке или куче, и могут или не могут с ними одновременно работать несколько потоков. Но с другой, представьте, что вы пишите программу, и оказалось, что переменная должна жить не в стеке, а в куче. Вы переписываете все, чтобы использовался Box. Потому вы понимаете, что на самом деле нужен Rc или Arc. Снова переписываете. А потом еще раз переписываете на обычную переменную в стеке. Все это - без нормальной IDE под рукой. И регулярки не помогут. Ну или же просто в стиле "Vec>>>", привет, Java! Но что самое печальное, компилятор уже знает о времени жизни всех переменных, он мог бы выводить все эти Box, Arc и так далее автоматически. Но почему-то эта часть работы переложена на программиста. Намного удобнее было бы просто писать val (в третьем-то тысячелетии!), а там, где надо, явно указывать Box или Rc. Разработчики Rust в этом смысле запороли всю идею.

Из-за этого, в частности, сильно сужается область применения Rust. Никто в здравом уме не станет писать на таком языке веб и серверсайд. Особенно учитывая, что он не дает существенных преимуществ перед теми же языками под JVM. Да и Go с нормальными легковесными потоками (не футурами) для этих задач выглядит куда более привлекательнее. С футурами, чтобы не прострелить себе ногу, нужно еще научиться работать, а вы говорите "безопасный язык". Да, у этих языков свои особенности, взять все тот же stop the world, но эта проблема решаемая, как распиливанием на микросервисы , так и другими приемами . И да, никто не будет транслировать Rust в JavaScript, писать на нем скрипты для раскладки в AWS, или использовать в качестве языка запросов к MongoDB. Под Android тоже вряд ли писать будут, но по другой причине - там сильно больше одной архитектуры, с JVM намного проще. Если вы вдруг думали, что Rust "подходит для всех задач", вынужден вас огорчить.

Ну и до кучи:

Макросы, как подпорка к излишней многословности, вызванной отсутствием нормальных исключений. Я уже писал о проблемах метапрограммирования , в частности, нормальную IDE для Rust мы вряд ли увидим из-за него. И я не уверен, но похоже, что у макросов в Rust даже неймспейсов нет.
Люди идиоты, а cargo очень поощряет стягивание пакетов напрямую из git-репозиториев, в обход Crates.io. В итоге велика вероятность получить такой же бардак с пакетами, как и в мире Erlang с его Rabar"ом. К слову, в мире Go, похоже, такая же ситуация.
Как многие новые языки, Rust идет по пути упрощения. Я в целом понимаю, почему в нем нет нормального наследования и исключений, но сам факт, что кто-то за меня решает такие вещи, оставляет неприятный осадок. C++ не ограничивает программиста в вопросах чем пользоваться, а чем нет.
Если уж идти по пути упрощения, то выкинуть бы уж все эти расширения языка. А то получается, как в мире Haskell, каждый программист пишет на своем диалекте.
Смарт поинтеры, если что, далеко не бесплатны и не приводят к предсказуемому времени сборки мусора. Какому-то потоку внезапно выпадает честь освободить очень глубокую структуру данных. Пока он ходит по лабиринту из мертвых ссылок, зависящие от него потоки терпеливо тупят. Та же проблема есть и в Erlang с его маленькими кучками, сам не раз наблюдал. Смарт поинтеры имеют и свои проблемы, ту же фрагменатцию памяти и утечки. Забыл викпоинтер в цеклической структуре, и все. И это в языке, претендующем на безопасность. Если хотите предсказуемого времени GC, либо изучайте поведение вашего приложения под нагрузкой, и предпринимайте меры (вспомним хотя бы те же пулы объектов), если время GC вас не устраивает, либо управляйте памятью вручную.
Кто-нибудь видел строгое описание семантики Rust? У него хотя бы memory model есть? Тоже мне "безопасный" язык, "доказывающий корректность" программ, который вообще-то может трактовать исходный код десятью разными способами, ха!
Не могу в очередной раз не напомнить, что проблема почти всегда в людях, а не в технологиях . Если у вас получается плохой код на C++ или Java вдруг тормозит, это не потому что технология плоха, а потому что вы не научились правильно ею пользоваться. Rust вы тоже будете недовольны, но уже по другим причинам. Не проще ли научиться пользоваться более популярными инструментами и начать их любить?

В общем и целом, ближайшие лет 5 я лучше будут инвестировать свое время в изучение C/C++, чем Rust. С++ - это промышленный стандарт . На этом языке успешно решают самые разнообразные задачи уже более 30 лет. А Rust и иже с ним - непонятные игрушки с туманным будущем. Про скорую смерть С++ разговоры идут как минимум с 2000-х, но писать на C/C++ за это время стали не меньше. Скорее наоборот. И мы видим, что язык развивается (C++11, C++14), для него появляются новые инструменты (вспомним хотя бы CLion и Clang), и соответствующих вакансий просто куча.

Программист на C++ всегда без труда найдет себе работу с более чем достойной зарплатой , а при необходимости быстро переучится на Rust. Обратное очень и очень сомнительно. Кстати, язык, если что - далеко не единственный и не решающий фактор при выборе нового места работы. Кроме того, опытный программист на C/C++ без труда вонзается в исходники PostgreSQL или ядра Linux, использует мощные современные инструменты разработки, а также имеет в своем распоряжении множество книг и статей (скажем, по OpenGL).

Берегите свое время и здоровье, их у вас не так много, как кажется!