> Is this[1] what you call "memory management"? Strictly speaking, it's one option; no worse than C. That said, I'd probably just manage my own arenas and avoi

> Is this[1] what you call "memory management"? Strictly speaking, it's one option; no worse than C. That said, I'd probably just manage my own arenas and avoid dynamic allocation. > Two can play at that game. You are completely wrong. If your best example of an environment where a GC might not be a good fit is game development, then you are in no position to use such absolute statements No need to get combative. I was quite clear--there are many systems that are frequently described as "not-GC friendly" (like games) for which Go's GC is suitable. These are soft real time systems. There are other hard real time systems for which Go's GC is not suitable, like the automotive systems I worked on in my last job. Go can serve hard realtime systems too (just use it like you would use C), but it's often not the best tool for that job. > Personally, I tend to add "I think" or "I believe" whenever I am making statements that are outside of my realm of expertise. I was an embedded engineer for a critical hard real time system in a previous life. This _is_ my area of expertise. > This prevents me from making a fool of myself If you say so. ;) > Good luck getting Go to run efficiently on a microcontroller without a ton of weird hacks. Granted, but this has nothing to do with GC. > ? Picking at random is an alternative to choosing a language by comparing candidate languages.