3 ms·

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

by nux6 14y ago

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.

batista 14y ago
I fail to see how Go is "unsuitable" for even the pro use case. Go could do a recording type application with minimal guaranteed latency just fine, and the GC won't stop it doing so.
- scott_s 14y ago
  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 http://researcher.ibm.com/researcher/view_project.php?id=174) which then allow them to be used for hard real-time systems.
  - luriel 14y ago
    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.
    - scott_s 14y ago
      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.
      - it 14y ago
        You can shut off the GC in Go: import "runtime" ... runtime.MemStats.EnableGC = false https://groups.google.com/forum/?fromgroups#!topic/golang-nuts/gPyersplzI8 https://groups.google.com/forum/?fromgroups#!topic/golang-nu...
pjmlp 14y ago
And yet there are sound manipulation tools developed in Java and .NET...
- pcwalton 14y ago
  Well, to be fair, Java and .NET have generational, concurrent, incremental garbage collectors.
scott_s 14y ago
That is not the definition of "hard real-time" that I, and others, use: http://en.wikipedia.org/wiki/Real-time_computing http://en.wikipedia.org/wiki/Real-time_computing 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.
jff 14y ago
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.

by nux6 14y ago

batista 14y ago

I fail to see how Go is "unsuitable" for even the pro use case. Go could do a recording type application with minimal guaranteed latency just fine, and the GC won't stop it doing so.

scott_s 14y ago
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 http://researcher.ibm.com/researcher/view_project.php?id=174) which then allow them to be used for hard real-time systems.
- luriel 14y ago
  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.
  - scott_s 14y ago
    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.
    - it 14y ago
      You can shut off the GC in Go: import "runtime" ... runtime.MemStats.EnableGC = false https://groups.google.com/forum/?fromgroups#!topic/golang-nuts/gPyersplzI8 https://groups.google.com/forum/?fromgroups#!topic/golang-nu...

pjmlp 14y ago

And yet there are sound manipulation tools developed in Java and .NET...

pcwalton 14y ago
Well, to be fair, Java and .NET have generational, concurrent, incremental garbage collectors.

scott_s 14y ago

That is not the definition of "hard real-time" that I, and others, use: http://en.wikipedia.org/wiki/Real-time_computing http://en.wikipedia.org/wiki/Real-time_computing 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.

jff 14y ago

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.