In my very limited understanding, hard real time systems collect memory in a fashion _more_ like this than previously. The idea is to use a ticky-tocky garbage

In my very limited understanding, hard real time systems collect memory in a fashion _more_ like this than previously. The idea is to use a ticky-tocky garbage collection system that always takes a certain amount of time ('tick') but guarantees the system enough usable time ('tock') to respond to the outside world in an appropriate fashion. The point, (again note I'm not an expert in this stuff) is that there's no such thing as an infinitely responsive real-time system - even hardwired analogue electronics, or a program running entirely in CPU cache, have a response time. So realtime always means that the system responds acceptably quickly for the application, without slowing down. Now as to how this applies to games, obviously a 10 ms pause is not a great help for updating a 60 Hz game every 16 ms. But for some lower speeds it could reduce latency and give an overall smoother feel to networked gaming. A couple of other posters on this thread have already mentioned tricks to get around this, if multiple processes can share the load and gracefully garbage-collect. But on the whole it seems like offering some configurability would make Go more versatile. In the extreme you might want to turn off the GC and make use of a manual free-type function. (I gather the Go developers oppose this on philosophical grounds).