> В третьем пункте — исходный код примера был заменён на другой код,

нет.

> По факту, да, докладчик прав — код на Rust трогает память, код на C++ не трогает.

докладчик пишет boost::stacktrace. когда он своими усилиями введет это в стандарт, С++ везде будет трогать память как раст. тупо потому что это соглашение о вызовах, а он сравнивает разный код (ud2 vs rust backtrace)

@Psilon Я тут на Akka Net пилю фигню и такое дело. Хотел строго типизированный актор сделать. Вроде есть там TypedActor и все такое. Но блин, на нем написано что он Деприкейтед. Шито тогда вместо него юзать и вообще как-то можно вместо нетипихированного IActorRef получить типизированный интерфейс как в Orleans?

> когда он своими усилиями введет это в стандарт
Когда введёт, тогда и поговорим.
Имеет смысл сравнивать текущее пололжение дел.

Там уже в комментах за меня показали, в целом.
Во втором пункте — «это баг не в rustc, это баг в LLVM» — юзеру на это сказочно пофиг, компилируя Rust ты получишь неопределённое поведение в том случае, который в Rust неопределённым поведением не считается.
В третьем пункте — исходный код примера был заменён на другой код, и далее сравнивался его ассемблерный листинг. По факту, да, докладчик прав — код на Rust трогает память, код на C++ не трогает. Тут следовало бы в качестве аргумента показать panic=abort или сказать: «в C++ это даёт UB в таком-то случае, если для вас это допустимо, то есть функция unreachable_unchecked!(), которая в явном виде сделает то же самое»
В четвёртом пункте опять код заменяется на другой, но там докладчик тоже хорош — делать вывод про быстрее/медленнее из одного сниппета это идиотизм.
В пятом пункте подмена утверждения. Представим, что у тебя есть старая проприетарная кодовая база на C — чтобы перейти на C++ тебе нужно приложить примерно ноль усилий, чтобы перейти на Rust — нужно писать обёртки. Наличие готовых обёрток над некоторыми библиотеками, сглаживает её (для этих библиотек), но не решает. Даже если обёртка есть, её нужно поддерживать в актуальном состоянии, что тоже дополнительная работа.
В шестом пункте спорно. unsafe { }, теоретически, действительно даёт возможность сделать только ограниченное количество вещей, но на практике ты можешь в ансейфе легко сломать любой инвариант, фактически «отключив» проверку. Вот, например, мгновенный UB — два мутабельных референса на одну точку:

let mut a = 0;
let b = &mut a as *mut i32;
let c = &mut a;
unsafe {
    let d: &mut i32 = std::mem::transmute(c);
}

у меня объясняется причина его появления. она такая же, как и в С++

По шестому пункту. UB - это не "отключение проверок", это UB.

Там уже в комментах за меня показали, в целом.
Во втором пункте — «это баг не в rustc, это баг в LLVM» — юзеру на это сказочно пофиг, компилируя Rust ты получишь неопределённое поведение в том случае, который в Rust неопределённым поведением не считается.
В третьем пункте — исходный код примера был заменён на другой код, и далее сравнивался его ассемблерный листинг. По факту, да, докладчик прав — код на Rust трогает память, код на C++ не трогает. Тут следовало бы в качестве аргумента показать panic=abort или сказать: «в C++ это даёт UB в таком-то случае, если для вас это допустимо, то есть функция unreachable_unchecked!(), которая в явном виде сделает то же самое»
В четвёртом пункте опять код заменяется на другой, но там докладчик тоже хорош — делать вывод про быстрее/медленнее из одного сниппета это идиотизм.
В пятом пункте подмена утверждения. Представим, что у тебя есть старая проприетарная кодовая база на C — чтобы перейти на C++ тебе нужно приложить примерно ноль усилий, чтобы перейти на Rust — нужно писать обёртки. Наличие готовых обёрток над некоторыми библиотеками, сглаживает её (для этих библиотек), но не решает. Даже если обёртка есть, её нужно поддерживать в актуальном состоянии, что тоже дополнительная работа.
В шестом пункте спорно. unsafe { }, теоретически, действительно даёт возможность сделать только ограниченное количество вещей, но на практике ты можешь в ансейфе легко сломать любой инвариант, фактически «отключив» проверку. Вот, например, мгновенный UB — два мутабельных референса на одну точку:

let mut a = 0;
let b = &mut a as *mut i32;
let c = &mut a;
unsafe {
    let d: &mut i32 = std::mem::transmute(c);
}

В C++ на том же коде он не появляется.
То, что появляется на другом коде с искуственно добавленной функцией — никак не опровергает исходный тезис.