Similar with malloc in C / new in C++, especially for short-living, repeating, in hot path. And then you hear: avoid allocations, use constant-size buffers or memory pools. Avoid spawning threads, use thread pools.
I think that people hyperoptimize for no reason though. How many applications are there that require no GC? I feel like you can write the no-gc code in Rust and then just use it from the C ABI from any GC language.
Maybe. Go code is designed to be readable and stable. My guess is that most Go code is running fine with garbage collection. There are always edge cases and then just choose another language.
The end state of every garbage collected language is a suite of tools to prevent garbage collection at all costs.
I think we can learn something here.
Similar with malloc in C / new in C++, especially for short-living, repeating, in hot path. And then you hear: avoid allocations, use constant-size buffers or memory pools. Avoid spawning threads, use thread pools.
I think that people hyperoptimize for no reason though. How many applications are there that require no GC? I feel like you can write the no-gc code in Rust and then just use it from the C ABI from any GC language.
Maybe. Go code is designed to be readable and stable. My guess is that most Go code is running fine with garbage collection. There are always edge cases and then just choose another language.
Go compiler has an advanced escaping analyzer. Wouldn't it be easier and better to add this noalloc-analyzer feature to golang directly?
I love it. Any thoughts on allowing (value type) Pointers into a Region?