Что делает Rust универсальным языком программирования

И где там эти динамические возможности демонстрируются? Я вижу статическую строку 'Excel.Application', вижу статические обращения типа XLApplication.Workbooks — это все написано в самом коде программы. Где динамика-то?

язык без библиотек — это не язык прикладного программирования — и не надо вводить людей в заблуждение

Пожалуйста дайте ссылку на то место, где я говорю, что Rust — это язык без библиотек.

А еще это вранье вдвойне — потому что модель память OLE не натягивается на владение Rust (просто так).

А вам не все равно, OLE-объектом вы оперируете в программе или нет, если результат "натягивается" на то, что вам нужно помимо вашего непосредственного участия? Object Pascal, считайте, повезло, что он имеет такое же представление vtable, как в C++. И что, мы теперь все языки с моделью памяти, отличной от C++, вычеркнем из разряда прикладных?

Вот вам пример из библиотеки intercom, как можно сделать API в Rust для работы с COM-объектами (они тоже основаны на vtable):

Rust COM server:

pub use intercom::*;

#[com_library(Calculator)]

#[com_class(Calculator)]
struct Calculator {
    value: i32
}

#[com_interface]
impl Calculator {
    pub fn new() -> Self {
        Self { value: 0 }
    }

    pub fn add(&mut self, value: i32) -> ComResult<i32> {
        self.value += value;
        Ok(self.value)
    }
}

C# COM client:

class Program
{
    [STAThread]
    static void Main( string[] args )
    {
        var calc = new Calculator.Interop.Calculator();
        calc.Add( 10 );
        var result = calc.Add( 100 );
        Console.WriteLine( result );
    }
}

Вся магия с указателями и прочим скрыта за атрибутными процедурными макросами.

Ну тогда это просто грязный пиар — язык без библиотек — это не язык прикладного программирования — и не надо вводить людей в заблуждение.

Становится чуть менее больно жрать кактус?

Прикрутили проволокой ООП к Си.

Ну, в этом же и была его концепция, если кратко :)

Можно посмотреть на Haskell и представить, как это все может заработать в императивном языке, заточенном под эффективность и без сборщика мусора )

Если серьезно, то одного единственного документа, наверное, нет. Но кое-что вырисовывается из набора RFC: https://github.com/rust-lang/rfcs/tree/master/text

Парсер языка Rust, кстати, относительно простой.

О, началась знакомая риторика.

В-третьих, Вы слишком много ожидаете от _первого_ релиза DFA.

Возможно, но для более простого примера — когда shortest и cut_prefix вызываются непосредственно — профилировщик лайфтаймов от Герба Саттера таки ловит ошибку, пусть и с ложно-положительным срабатыванием, а -fanalyzer — нет, так что какие-то ожидания у меня всё-таки были.

Во-вторых, надо таки читать учебники, чтобы писать программы правильно.

Ух, сколько гонора. Гм, а не подскажете, где можно найти учебник, который бы покрывал C++17? C++ core guidelines — это не учебник и не завершённая вещь.

Во-первых, в учебниках написано, что string_view не рекомендуется возвращать по значению, надо возвращать string, как раз из-за подобных случаев.

То есть string_view::substr должен возвращать string, я понял. А если серьёзно — ну что не так с example_ok по ссылке выше? Тут создаётся временная строка, да, но результат cut_prefix заведомо держит ссылку на данные str, а не n_str, так что тут всё в порядке. Собственно, если расписать типы shortest и cut_prefix, то в Rust им можно приписать разные типы:

fn shortest<'a>(a: &'a str, b: &'a str) -> &'a str {
    if a.len() < b.len() { a } else { b }
}

fn cut_prefix<'a>(prefix: &str, s: &'a str) -> &'a str {
    if s.starts_with(prefix) {
        &s[prefix.len()..]
    } else {
        s
    }
}

То есть информация о связях между аргументом и результатом непосредственно выражена в типе. И компилятор Rust эту информацию эксплуатирует:

// компилируется
fn example_ok(n: u32, s: &str) -> &str {
    let n_str = n.to_string();
    cut_prefix(&n_str, s)
}
// не компилируется: "cannot return value referencing local variable `n_str`"
fn example_err(n: u32, s: &str) -> &str {
    let n_str = n.to_string();
    shortest(&n_str, s)
}

И это именно информация в типах, а не кросс-анализ потока исполнения: я могу заменить реализации shortest и cut_prefix на заглушки и всё равно получить ошибку компиляции в нужном месте. Та же логика работает и в случае вариантом example, который оперирует переданным коллбеком:

fn example_hof_ok(
    n: u32,
    s: &str,
    func: for<'a> fn(&str, &'a str) -> &'a str
) -> &str {
    let n_str = n.to_string();
    func(&n_str, s)
}

fn example_hof_err(
    n: u32,
    s: &str,
    func: for<'a> fn(&'a str, &'a str) -> &'a str
) -> &str {
    let n_str = n.to_string();
    func(&n_str, s)
}

То есть в example_hof_ok тип функции func прямо говорит, что возвращаемое значение связано лишь со вторым аргументом, а в example_hof_err функция func может возвращать данные, связанные с любым аргументом. example_hof_err не компилируется, и для проверки даже не нужно её вызывать. Ну и, опять таки из-за того, что отношения выражены в типах, мы можем вызвать example_hof_ok с cut_prefix и не можем с shortest (тык).

Вообще, строковые срезы в программах на Rust применяются достаточно активно именно потому, что компилятор ловит подобные ошибки. У программиста на C++ тут две альтернативы, и обе так себе: либо полагаться на себя и ненадёжный статанализатор, либо на всякий случай таки делать string и зря выделять память в куче.

Спасибо, надо всё-таки побыстрее комментарии писать.