Здравствуйте, gandjustas, Вы писали:

S>>Ведь Rust отстает, получается.
G>Да, с точки зрения синтаксических возможностей раст довольно бедный язык. ? оператор есть, а ?? нет. И ! нет, надо везде писать .unwrap().

"unwrap" как раз не надо везде писать, он нужен для тестов или "main" функции,
"unwrap" в коде функции как раз антипатерн.

G>Нет оператора is как C#, предлагается через громоздкий if let делать.
G>А еще нет перегрузок функций, дефолтных параметров, нет функций с переменным числом параметров.

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

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

Из-за совместимости с С функции с переменным числом параметров как раз поддерживаются:

extern "C" {
    pub fn printf(__format: *const ::std::os::raw::c_char, ...) -> ::std::os::raw::c_int;
}

G>Операции с указателями крайне неудобны, так как операция разыменовывания имеет меньший приоритет и нет оператора -> как в C. Вроде как сделано для того, чтобы люди меньше писали unsafe, но некоторые вещи сложно эффективно выразить в safe.

Указатель можно превратить в ссылку одним "unsafe", а потом обращаться ко всем полям через ".",
и эффективность от этого никак не пострадает.

G>Есть еще и проблемы в семантике: работа с Error, пробрасывание ошибок и стектрейсы для error,

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

G>отсутствие наследования (которое в каждом втором фреймфорке переизобретено).

Наследование-то есть. Но наследование поведения, а ООП как раз о поведении.
Наследования данных действительно нет, но для ООП это и не нужно, просто так исторически
сложилось, что классы наследовали и поведение и данные.

G>Отсутствие стандартного метода работы с метаданными и вообще отсутствие высокоуровневых концепций в стандартной библиотеке,

Здесь не понял о чем речь.

G>async прибитый к конкретному движку.

Это не правда, "async" в embedded применяется,
там не просто "tokio" нет, там даже стандартной библиотеки не используется,
а "async" прекрасно работает. Там же по сути концепций раз два и обчелся: Waker, Context и Future.
И их может кто угодно использовать, как это может считаться "прибитым к конкретному движку" непонятно