[runevault]

Maybe at small scales like embedded, but Go's GC has proven problematic even with static memory allocation. Some company (Discord?) ran into issues where the large heaps were scanned every 2 minutes because Go refuses to go longer than that w/o a GC check even if it has no reason to believe it needs to.

[cesarb]

> Some company (Discord?) ran into issues where the large heaps were scanned every 2 minutes because Go refuses to go longer than that w/o a GC check even if it has no reason to believe it needs to.

https://blog.discord.com/why-discord-is-switching-from-go-to...

"After digging through the Go source code, we learned that Go will force a garbage collection run every 2 minutes at minimum. In other words, if garbage collection has not run for 2 minutes, regardless of heap growth, go will still force a garbage collection."

Discussed here at https://news.ycombinator.com/item?id=22238335

[runevault]

Yup that's what I was thinking of, appreciate you digging up the article detailing my point.

[mst]

The go team have done amazing work minimising mutation pause times. I'm skeptical I would ever be comfortable using it for code that close to the metal, but if any mark and sweep garbage collected language is going to one day reach a point where that's solely prejudice on my part rather than part prejudice and part technological realism go is probably the most likely candidate.