C++ vs Rust: правда ли, что Rust тупо сложнее крестов в базовых сценариях применения?

можно простыми структурами пользоваться.

нет нельзя:

auto cing =  Disconnected{}.connect();
auto ced = cing.established();
ced = cing.established(); // ой, сломалось, по протоколу такое можно только 1 раз проделать
ced.successed_ping().drop();

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

Ну и, конечно же, отдельные ветки для обработки успешного и неудачного пингов – это доставляет.

А что должно быть? не отдельные ветки - это как? никакой компилтайм в будущее не может заглянуть и будет разделение в рантайме и именно 2 не 3 не 1.5, это суть выбора из булевского значения(и дело не в смысле термина пинг)

А можно для дебилов пояснить, этот кусок кода должен показать что? Вопрос не для тролления, просто я правда туповат и не понял, но мне очень интересно.

он же вот так записал.

Disconnected{}.connect()
  .established()
  .successed_ping()
  .drop();

нет тут возможности вызвать два раза established поскольку после первого вызова established уже будет другой тип обьекта.

И чем оно лучше этого?

use std::thread;
use std::time::Duration;

#[derive(Debug, Clone, Copy)]
enum State {
    Disconnected,
    Connecting,
    Connected,
}

struct Connection {
    state: State,
}

impl Connection {
    fn new() -> Self {
        Connection { state: State::Disconnected }
    }

    fn connect(&mut self) {
        match self.state {
            State::Disconnected => {
                println!("Connecting...");
                self.state = State::Connecting;
                thread::sleep(Duration::from_secs(2)); // Эмуляция подключения
                self.state = State::Connected;
                println!("Connection established.");
            }
            State::Connecting => {
                println!("Already connecting.");
            }
            State::Connected => {
                println!("Already connected.");
            }
        }
    }

    fn ping(&self) {
        match self.state {
            State::Connected => {
                println!("Ping succeeded.");
            }
            _ => {
                println!("Cannot ping from current state.");
            }
        }
    }

    fn drop(&mut self) {
        match self.state {
            State::Connected | State::Connecting => {
                println!("Dropping connection.");
                self.state = State::Disconnected;
            }
            State::Disconnected => {
                println!("Already disconnected.");
            }
        }
    }
}


fn main() {
    let mut connection = Connection::new();

    connection.connect();
    connection.ping();
    connection.drop();
}

И чем оно лучше этого?

Простите, а зачем я должен что-то объяснять тому, кто писать научился, а читать нет?

нет нельзя:

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

Во-вторых, вы бы определились с тем, что вы хотите продемонстрировать: удобство Rust-а в декларативном описании КА или же такие фишки Rust-а, как «затенение» переменных (или как оно там называется официально) и деструктивное перемещение.

А что должно быть?

КА с внутренним состоянием и реакцией на внешние воздействия.

не отдельные ветки - это как?

У меня есть ощущение, что вы задачу КА пытаетесь заменить на другую задачу, а именно: у вас есть объект X у которого есть метод x, и после вызова метода x объект X должен измениться так, чтобы у него можно было вызывать только методы y и z, а метод x – нельзя.

Это разные задачи, а общего в них лишь то, что вы можете попытаться свести к свою задачу к проблеме КА.

Хотя решаться ваша задача должна именно за счет конструирования нового объекта и уничтожения старого. Отсюда и появляется ваш код, который возвращает экземпляры разных типов с разным API.

Да, в Rust-е это делается проще, чем в C++. Но блин, Rust появился на 30 лет позже C++ и с учетом кучи ошибок, допущенных в C++. Было бы странно, если бы Rust нигде не был бы лучше.

Однако, подобное решение возможно и на C++, пусть даже и без такого контроля со стороны компилятора. Но, самое главное, к проблеме декларативного определения КА оно не имеет отношения.

Попробуйте представить этот ваш «КА» в виде объекта, который должен лежать в каком-то другом объекте (например, в объекте session), должен иметь какое-то внутреннее состояние (вроде дескриптора сокета, времени последней активности в сокете, буфер с остатками пока еще неразобранных данных) и должен реагировать на внешние воздействия, меняя свое состояние в зависимости от них.

Насколько полезным здесь окажется то же самое «затенение» переменных?

Что помешает разбить как я продемонстрировал, кроме как предупреждение в документации. Ну и в таком виде оно, как раз малополезно

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

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

Во-вторых, вы бы определились с тем, что вы хотите продемонстрировать: удобство Rust-а в декларативном описании КА

вот как раз про это было в первом примере, про декларативность я не заявлял это выше докополись что КА у меня визуально не в виде таблички(они почему-то связывают это с декларативностью)

КА с внутренним состоянием и реакцией на внешние воздействия.

и в обоих примерах это всё есть, КА очень абстрактное понятие и может иметь разные реализации, отличающиеся от того что вы считаете единственно верной, поэтому ничего я не пытаюсь заменить или свести на какие-то другие задачи - это всё детали реализации

Да, в Rust-е это делается проще, чем в C++. Но блин, Rust появился на 30 лет позже C++ и с учетом кучи ошибок, допущенных в C++.

И я ровно это продемонстрировал прямо по теме топика. Что за наезды тогда? Если что нет у меня цели обосрать плюсы, я сам их использую/вал, поэтому можно выключить в голове царский триггер на «плюсы обижают»

Попробуйте представить этот ваш «КА» в виде объекта, который должен лежать в каком-то другом объекте (например, в объекте session), …

conn и есть такой «объект» , может храниться, передаваться, содержать что угодно, и всё это не тратя ресурсов на логику самого автомата,

и должен реагировать на внешние воздействия, меняя свое состояние в зависимости от них.

я и это показал(в отличие от вашего примитивного примера), но только это у вас вызывает странное ГЫГЫ вида «отдельные ветки для обработки успешного и неудачного пингов – это доставляет.» которое вообще заставляет сомневаться в вашей адекватности, как ещё в рантайме можно среагировать на событие булевского типа которое имитируется bool_fun()? В чём собственно гыгы?

«затенение» переменных

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

Так может и сами потрудитесь прочитать тред выше где уже есть многие ответы

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

Неужели это настолько невероятная вещь?

вещает банальности игнорируя ответы

Если то, что я вам пишу выглядит как банальности, про прассыти, но я вынужден расписывать причины, по которым задаю вам вопросы. Например, у меня есть устойчивое ощущение, что у вас превратное понимание понятия КА, поэтому мне приходится описывать КА, чтобы более точно определить предмет разговора.

про декларативность я не заявлял это выше докополись что КА у меня визуально не в виде таблички(они почему-то связывают это с декларативностью)

Так ведь те, кто докапывался, они же правы. В примере на C++ чистой воды декларативность. Вы ее предлагаете заменять на рукопашный код, что людям и не нравится. Более того, вы предлагаете несколько вариантов, второй из которых вообще выглядит откровенно бесполезной херней. На что вам указывают, но вы предпочитаете вести себя в стиле «малолетнего дебила», а именно «ах эти замшелые деды не видят красоты!»

и в обоих примерах это всё есть

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

И я ровно это продемонстрировал прямо по теме топика.

Нет, увы.

Что за наезды тогда?

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

conn и есть такой «объект» , может храниться, передаваться, содержать что угодно, и всё это не тратя ресурсов на логику самого автомата,

Ну тогда покажите как это будет работать, а то я не понимаю.

Вот, допустим, в C++ (как и в каком-нибудь Python-е, Java или D) у нас будет что-то вроде:

struct session {
  connection _conn; // connection -- это и есть КА со своим состоянием.
  ...
};

// Коллбэки которые где-то когда-то вызываются и воздействуют
// на содержимое session.
void on_incoming_data(session & s, data && d) {
  s._connection.push_event(incoming_data{std::move(d)});
  ...
}
void on_connected(session & s, connection_info && ci) {
  s._connection.push_event(connected{std::move(ci)});
  ...
}
void on_connection_lost(session & s) {
  s._connection.push_event(disconnected{});
  ...
}

У ваших же conn у каждого свой новый тип после каждой операции с эффектом деструктивного перемещения. Как вы этот conn поместите в session?

я и это показал(в отличие от вашего примитивного примера)

Нет. И как раз мой примитивный пример является тому илюсстрацией.

но только это у вас вызывает странное ГЫГЫ вида «отдельные ветки для обработки успешного и неудачного пингов – это доставляет.» которое вообще заставляет сомневаться в вашей адекватности

Пока что разговор с вами заставляет усомниться в том, что у вас есть опыт работы с КА. Больше похоже, что вы прочитали главу в Rust book-е и на этом все.

В Паскаль превратился Algol-W, которым Хоар и Вирт пытались заменить Алгол-60. Но вместо этого комитет по разработке стандарта сделал еще один мертворожденный Алгол-68.