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

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

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

Z>"unwrap" как раз не надо везде писать, он нужен для тестов или "main" функции,
Z>"unwrap" в коде функции как раз антепатерн.
Например я пишу приложение, которое pdf файлы разбирает на кусочки. Если друг не получилось прочитать или записать файл, то программа должна упасть. У меня нет других вариантов обработки этой ошибки. Причем упасть желательно со стектрейсом. Почему в этом случае я не должен использовать unwrap?

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

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

Твоя вера сильна.



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

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

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

Ты же не можешь в расте сделать свою функцию с переменным числом параметров. Даже если ты её потом экспортируешь.

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

Z>Указатель можно превратить в ссылку одним "unsafe", а потом обращаться ко всем полям через ".",
У тебя есть указатель на структуру А, в которой есть поле — указатель на B, напиши как будет выглядеть обращение к этому полю.

Z>и эффективность от этого никак не пострадает.
Аминь


G>>отсутствие наследования (которое в каждом втором фреймфорке переизобретено).
Z>Наследование-то есть. Но наследование поведения, а ООП как раз о поведении.
То что в расте вы называете наследованием поведение — это экстеншн-методы в извращенной форме.

Z>Наследования данных действительно нет, но для ООП это и не нужно, просто так исторически
Z>сложилось, что классы наследовали и поведение и данные.
Ага, не нужно. Открываем доку https://rust-cli.github.io/book/tutorial/cli-args.html прямо с оф сайта видим:

use clap::Parser;

/// Search for a pattern in a file and display the lines that contain it.
#[derive(Parser)]
struct Cli {
    /// The pattern to look for
    pattern: String,
    /// The path to the file to read
    path: std::path::PathBuf,
}

fn main() {
    let args = Cli::parse();
}

Упс, наследование поведения через макросы. Даже ооп как такового нет, а наследование есть.

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

G>>Отсутствие стандартного метода работы с метаданными и вообще отсутствие высокоуровневых концепций в стандартной библиотеке,
Z>Здесь не понял о чем речь.
Где в стандартной библиотеке json, http client, http server, unicode. Так чтобы их не стесняясь использовать и в создании своей библиотеки?


G>>async прибитый к конкретному движку.
Z>Это не правда, "async" в embedded применяется,
Z>там не просто "tokio" нет, там даже стандартной библиотеки не используется,
Не понимаю твою мантру. Ты хочешь сказать что можно написать веб-сервис, а потом например заменить tokio на async-std, не переписывая прикладной код?

Z>а "async" прекрасно работает. Там же по сути концепций раз два и обчелся: Waker, Context и Future.
Концепций может и мало, а их реализаций много. И они несовместимы между собой. И нет какой-то типовой, всклоченной в стандартную библиотеку.

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