5 ms·

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

by 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...

5 ms·

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

by 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...