That's debatable, as you can write the code in such way that it does not trigger allocations in a specific situation where it might be critical.

Having used Native Oberon in the 90's, I became convinced that system programming languages with GC are possible.

Latest versions of AOS even had video players with good framerate written in Active Oberon, with some Assembly snippets.

However, in the Oberon family, besides NEW, the other implicit memory allocations are only triggered by string manipulation and starting tasks, if I recall correctly.

That helps, but in some domains, it's 100% unacceptable. For example, kernels or more intense, high-end video games. And can you tell Go's GC not to run for a period of time? I thought that it could stop the world at any time.

Don't get me wrong, I do 90% of my coding in a garbage-collected language. But any mandatory GC does limit your domain.

> That helps, but in some domains, it's 100% unacceptable. For example, kernels or more intense, high-end video games.

However such systems exist.

Kernels => Native Oberon, Blue Bottle, EthOS. All desktop oriented systems used at ETHZ in Switzerland during the 90's. Used for teaching OS design, and a few teachers even used them as their main system.

High end games => The Witcher for XBox 360. They made use of a GC runtime in the game engine.

> But any mandatory GC does limit your domain.

I tend to think the limit is more religious than practical.

Please note that I defend GC enabled systems programming languages, not necessarily Go for such domains.