> Basically [Rust] can enforce that every resource that is used, is properly opened, is properly accessed, has (one writer) OR (multiple readers and no writer) at a time, and is properly closed. It can do this for memory, files, sockets, as well as arbitrary constructs of your choice.

Unfortunately, this is not true.

https://fasterthanli.me/articles/a-rust-match-made-in-hell

https://old.reddit.com/r/rust/comments/1v54et2/what_are_the_...

https://old.reddit.com/r/rust/comments/1v54et2/what_are_the_...

Mojo arguably does this better, by having both implicit and explicit destructors, and forcing developers to call explicit destructors, well, explicitly. A lock's destructor must be called manually if it is marked explicit, and thus developers reading Mojo code will presumably not be in doubt about where and when the lock is released.

https://mojolang.org/docs/manual/lifecycle/death/#explicitly...

This is different from Rust. In the following Rust edition 2024 code, the only difference between the two examples is a pair of "{}" around the match subject, but if you run them, one of them deadlocks, due to how temporary lifetime extension is handled in Rust.

https://play.rust-lang.org/?version=stable&mode=debug&editio...

https://play.rust-lang.org/?version=stable&mode=debug&editio...

Temporary lifetime extension is a mess in Rust, C++ and Zig. It is not a mess in C, more or less, since compound literals are arguably the only feature of C that have something like temporary lifetime extension, so any problems with temporary lifetime extension in C are limited to compound literals.