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

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

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

G>То что в расте вы называете наследованием поведение — это экстеншн-методы в извращенной форме.

Почему? Чем реализация трейта отличается от реализации интерфейса? И чем наследование трейтов отличается от наследования интерфейсов?

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

G>use clap::Parser;

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

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

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

То, что (некоторые) процедурные макросы навешиваются через derive ещё не делает это наследованием.

G>В этом и проблема.

В чём? Ну и всё-таки есть ли прибитость к движку или нет?.. Так-то в C# ты вообще "движок" поменять не можешь и ничего.