> В частном хватает std::shared_ptr<>.

Ты сейчас говоришь про случай описанный в новости, или просто произносишь общую фразу о том, что иногда все эти сложности решаются при помощи shared_ptr?

Если первое, то там оно не решается при помощи shared_ptr. Там память была освобождена, но не была отмаплена.

Если второе, то да, иногда shared_ptr помогает, а иногда оказывается таким тормозом, постоянно сбрасывая кеши, то лучше бы его и не было.

> А Rust что делает? unique_ptr выполняет на этапе компиляции

Неее... В расте есть аналог shared_ptr -- то ли Rc, то ли Arc, я не уверен, не знаю как себя shared_ptr ведёт в многопоточном окружении. Но вот аналога unique_ptr в расте нет. Есть что-то похожее на это, но это только если смотреть жопой и с большого расстояния.

Если тип не Copy (что дефолтом вешается на новые типы), то он как бы позволяет иметь не больше одного mutable указателя на значение. Во всяком случае, если верить маркетингу. Реально ситуация сложнее, глянь на код:

fn foo(v_foo: &mut Vec) { ... }
fn bar(v_bar: &mut Vec) { foo(v_bar); }
fn main() {
    let mut v = Vec::new();
    bar(&mut v);
}

Когда на стеке оказывается стековый фрейм foo, одновременно существуют три указателя на этот несчастный Vec. Точнее в main он как бы и не указатель вовсе, он присутствует значением (в отличие от unique_ptr, который именно что ptr), но тем не менее это мутабельная переменная позволяющая менять Vec, и в стековых фреймах foo и bar в каждом по мутабельному указателю. Три мутабельных ссылки на одно значение!

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

Ещё пачка отличий unique_ptr от положения дел в расте вызвана тем, что в расте move'ы просчитываются статически, в C++ они насквозь динамичны, они по-определению shallow copy, и хрен заставишь оптимизатор выкинуть все эти ненужные копирования.