1. 19
  1.  

  2. 2

    Pretty impressive, I wonder at what point go could be considered for realtime applications? What’s the acceptable threshold? I’m guessing 0ms, so though cool I doubt anyone’s mind is really changed by this.

    1. 10

      The Go garbage collector, and the Go runtime in general is not a real-time program. It is optimized for latency, but real-time it is not. There is no guaranteed bounded execution time.

      It’s possible to write a real-time runtime, but it would have to be a new runtime.

      1. 6

        they are hard real time and soft real-time programs. For a soft real-time program that might be enough.

      2. 5

        “Realtime” doesn’t necessarily entail having zero gc pauses, but not having them helps. To have a realtime garbage collected application I’d imagine your gc pause would have to have a worst-case (provable, or something similar that’s good enough to say it’s very very likely to be) pause time to keep the rest of the program from missing its deadline through a certain execution path. Having measurably consistent 1ms or less pause times makes this very plausible for a variety of realtime applications.

        1. 1

          For e.g. controlling a cars brakes I’d guess the the acceptable pause is on the order of microseconds. For lots of other seemingly-realtime things, 1ms is fine.