Comment by IshKebab
12 hours ago
I don't think it's really that bad in Rust. If you're happy with an arena in Zig you can do exactly the same thing in Rust. There are a ton of options listed here: https://donsz.nl/blog/arenas/
Some of them even prevent use after free (the "ABA mitigation" column).
I'm not super experienced with zig, but I always think that in the same way that rust forces you to think about ownership (by having the borrow checker - note: I think of this as a good thing personally) zig makes you think upfront about your allocation (by making everything that can allocate take an allocator argument.).
It makes everything very explicit, and you can always _see_ where your allocations are happening in a way that you can't (as easily, or as obviously - imo) in rust.
It seems like something I quite like. I'm looking forward to rust getting an effects system/allocator api to help a little more with that side of things.
The problem is deallocation... unless you tie the allocated object to an arena allocator with a lifetime somehow (Rust can model that).
Yep, rust forces you to think about lifetimes. Zig only suggests it (because you're forced to think about allocation, which makes you naturally think about the lifetime usually) but does not help you with it/ensure correctness.
It's still nice sometimes to ensure that you have to think about allocation everywhere, and can change the allocation strategy for something that works for your usecase. (hence why I'm looking forward to the allocator api in rust to get the best of both worlds).
That's true and I liked the idea of it until I started writing some Zig where I needed to work with strings. Very painful. I'm sure you typically get a bit faster string manipulation code than what you'd get with Rust but I don't think it's worth the cost (Rust is pretty fast already).
Can't agree more. I hope someone puts some work into a less painful way to manage strings in std. I would but I don't manipulate strings quite enough to support usecases more than basically concatenation...
No, you can't do the same thing in Rust, because Rust crates and the standard library generally use the global allocator and not any arena you want to use in your code.
I mean you can store the nodes in an arena so you don't have to deal with the borrow checker getting upset with your non-tree ownership structure. That's the context. We weren't talking about arena use for speed/efficiency purposes. In that case you are right; it's much more awkward to use custom allocators in Rust.
Which is hardly any different from me using PurifyPlus back in 2000.
It's very different.