4 ms·
Nim is built like this. The gc is opt-in by type and manual memory management is simple. All other types are stack allocated by default. The new gc is pretty m
by arc619 5y ago
Nim is built like this. The gc is opt-in by type and manual memory management is simple. All other types are stack allocated by default.
The new gc is pretty much compiler assisted scope managed smart pointers as well. Also when using the gc you can build your own types with custom create/free/copy/move operators to do what you want without worrying about a stop the world gc.
Using the arc gc pretty much compiles down to what you'd do manually. For cycles you can use the orc gc, again it's all opt in.
I find this a great balance of productivity and performance, where it's easy to have high control when you want it, and still get good performance when you're not bothered.
- elcritch 5y ago+1 for Nim and being usable without a GC or for manual memory management like dealing with C apis. Though to be fair, quite a few types in the stdlib are heap based. But you can make your own static heap pool. With the new ARC & move semantics, Nim has hit a sweet spot, IMHO. It's like the language struggled to find a fit for a long time. But ARC allows very low overhead memory safety, perfect for mcu's and wasm in particular. Though perhaps Swift could be a contender in this arena as well with its ARC, but it's development is so Apple centric. What's interesting to me is that with move semantics and smarter compiler analysis, an ARC based GC overhead approaches that of Rust's compile time lifetime memory management. For any non-trivial program Rust seems to use a lot of Rc's or copies to get around lifetime analysis issues. So if the compiler can automatically figure out lifetimes in code it can eliminate many ARC operations. I hope more languages adopt more flexible ARC based gc's or improve on rusts ergonomics.