Comment by anonymoushn

> The "leaky abstractions" argument doesn't work for me. E.g. in a Java API you don't commit (at the language level) to the ownership of passed-in or returned mutable objects. In Rust, you do, and the author claims this is a problem. I say that in fact you depend on the ownership of the referenced object either way; Rust forces you to write down what it is and enforce that the callers honor it, while in Java you cannot. Arguably therefore Rust is less leaky in that hidden assumptions are documented and enforced at the API layer.

A lot of programs and large parts of a lot more programs just don't need these concepts at all and would run correctly with a GC that did not collect any garbage, memory permitting. Most Python code I write is in this genre.

On the flip side, at work we mainly work on a low-latency networked application that has per-coroutine arenas created once at startup and long-term state created once at startup. The arenas are used mostly for deserializing messages into native format to apply to the long-term state and serializing messages to wire format. There's not much benefit to be had from writing all the time that everything that isn't on the stack belongs to the per-coroutine arena, except for all instances of like 3 structs, which belong to the long-term state.