E.g. any app with [record] button need to meet 'mostly' predicted system latency, that's 'soft-real-time'. Any professional app with [play] and [record] button needs a minimal warranted latency, that's 'hard-real-time'. Go is unsuitable for both.
Hard real-time generally means that you have an actual deadline to finish your computation, and Very Bad Things will happen if you miss that deadline. Both of your examples are soft real time.
Your operating system could very well screw you anyway; a full-on Linux OS (for instance) is very very "noisy". See the FTQ (Fixed Time Quantum) benchmark for more info.
While I agree that Go is suitable for his examples, it's not suitable for hard real-time. As far as I know, its GC does not have bounded latencies. There are GCs that do have bounded latencies (see the Metronome project for Java's GC: http://researcher.ibm.com/researcher/view_project.php?id=174) which then allow them to be used for hard real-time systems.
This is not really an issue with the language but with the implemetnation and most languages/libraries/OS-es are not suited for "hard real-time" either.
How many people are writing "hard real-time" code? I suspect not many, and yes, for them probably Go is not the right tool at the moment, but also in great part because nobody has needed/wanted to use Go in such environments yet.
Requiring garbage collection is a language issue, not just an implementation issue. (Note that I do not think GC is a bad thing, but it matters a great deal in this context.) Making GC work in hard real-time system is a Hard Problem. I think you greatly underestimate how difficult it is, given your final sentence. Read the Metronome project I linked to.
You are correct that not many people write hard real-time code; it's generally found in such things as software controlling planes, power grids or power plants.
