Well the system is much better then nothing, but I hope they do a second iteration.
Even in the dewey eyed early years, Go saw STW latency in the hundreds of milliseconds. By 1.8 it's in the hundreds of microseconds.
Your hard-real-time is out the window as soon as routing and UDP is involved. The intent is "real time bounded by the amount of time it would take doctors to react to a code blue (heart issue/failure". One second of reaction (thousands of gc's, dozens of health checks, a near eternity in program time) isn't going to make a difference when human reaction time latency is hundreds of milliseconds.
Call it "live streaming" if that sounds more objective, but conceptually if the clients (humans) don't perceive a difference in state, it's real time (to them).
Save the milliseconds-hard-real-time talk for rockets and cars.
https://blog.golang.org/ismmkeynote
https://www.reddit.com/r/golang/comments/aetba6/gcs_stw_paus...
Would love to see a worst case analysis for go though. (My worry is, that long running applications are more prone to extensive gc stw, since os starts to swap pages, and gc tries to access them, might take a while)
Of course if you can guarantee that go always has stw gc for less than a second (or even 10 seconds) that would be great (and make go a hard real time language, of course not a very fast one)
In my mind "real time" as a term of art applies to things like hardware control systems with very strict tolerances.
Although, as a hacking challenge I'd love to see the most catastrophic delay one could plausibly accidentally code into a go application.