[tancop]

most of that criticism only works on C++. rust does enforce RAII but uses stack allocation for locals by default instead of touching the heap so it skips the slow part.

on the other hand there are no constructors (just normal functions) so you cant initialize values in place, only stack allocate and return. i think rust needs to add in place init and change the rules from "always init at declaration site" to "must be initialized at first use" like kotlin.

the big missing piece is custom allocators that let you use something like a bump arena with the same convenience as system malloc. they already exist on nightly but nobody knows when they will land on stable.

honestly thats the biggest problem with rust, they come up with a lot of useful changes but then take ages to stabilize because the core team is overworked. they also have a kind of perfectionist culture as a reaction to all the half baked features shipping in C++.

there should be a stage between nightly and full release where feature is in stable toolchains behind a cfg flag and you get a warning if upstream crates use it. show commitment to shipping it in time but still make it clear that it can change (in minor incompatible ways) before release.

[scott01]

Thanks for this, I’m actually learning Rust (albeit slowly) atm, and still can’t wrap my head around how arena allocs would fit the borrow checker

[kibwen]

There are several libraries for doing arena allocation in Rust, e.g. bumpalo: https://crates.io/crates/bumpalo , see the documentation for examples (it's quite easy to use and fits the borrow checker very well). The comments in here regarding Rust are somewhat misleading; Rust doesn't require unstable/nightly features to do this sort of stuff. What's unstable in Rust right now is a standardized interface for generically working with allocators (see https://github.com/rust-lang/rust/pull/157428 for the most recent progress), including support for the containers provided by the stdlib.

[nickmonad]

I haven't written any serious Rust in a while, but I assume there is some kind of lifetime annotation involved. The "objects" allocated in the arena have to be explicitly given the same lifetime as the arena itself. I have no idea how that looks syntactically.

[whytevuhuni]

> honestly thats the biggest problem with rust, they come up with a lot of useful changes but then take ages to stabilize because the core team is overworked

On the contrary, that has been one of Rust's biggest strengths. My impression when reading through stdlib was that they got so many things right, and for that to happen, things need to be thought out properly.

Case in point, it'd be such a shame if they stabilized the allocator API, only for us to forever regret never getting the storage API [1] instead, or vice-versa, depending on which one turns out to be more pragmatic.

> they also have a kind of perfectionist culture as a reaction to all the half baked features shipping in C++.

And that's a good thing! Some people really dislike the constant influx of new features due to the overwhelming complexity it leads to. So if we do have new features, they better be worth it.

[1] https://github.com/rust-lang/rfcs/pull/3446