5 ms·
Go achieves those low pause times by allocating 2x memory to the heap than it's actually using. There's no free lunch with GC.
by roca 6y ago
Go achieves those low pause times by allocating 2x memory to the heap than it's actually using. There's no free lunch with GC.
- pjmlp 6y agoSame applies with manually memory management, you get instead slower allocators unless you replace the standard library with something else, and the joy of tracking down double frees and memory leaks.
- roca 6y agoI'm using Rust, so no double frees and no accidental forgetting to call free(). Of course you can still have memory leaks, but that's true in GC languages too.
- pjmlp 6y agoThat is not manually memory management though, and it also comes with its own set of issues, like everyone that was tried to write GUIs or games in Rust is painfully aware of. There is no free lunch no matter what one picks.
- roca 6y agoThat's true. The comment by mlwiese up-thread, that I responded to, praised Go's low GC latency without mentioning the heavy memory and throughput overheads that come with it. I felt it worth pointing out the lack of a free lunch there; I think a lot of casual Go observers and users aren't aware of it.
- pjmlp 6y agoAgreed, although if Go had proper support for explicit value types (instead of relying in escape analysis) and generics, like e.g. D, Nim, that could be improved.
- AnIdiotOnTheNet 6y agoI don't think that's as hard as you make it out to be. Notably, Zig does not have a default allocator and its standard library is written accordingly, making it trivial to ensure the use of the appropriate allocation strategy for any given task, including using a debug allocator that tracks double-free and memory leaks.
- pjmlp 6y agoHas Zig already sorted out the use-after-free story?
- AnIdiotOnTheNet 6y agoNo, and as far as I am aware it makes no attempt to do so other than some allocators overwriting freed memory with a known signature in debug modes so the problem is more obvious.