6 ms·

Your C code looks very unidiomatic to me, but I guess that is relatively a matter of taste (still I don't understand why would somebody use C if they don't like

by luriel 14y ago

Your C code looks very unidiomatic to me, but I guess that is relatively a matter of taste (still I don't understand why would somebody use C if they don't like to write code in the 'classic' C style as seen in the original Unix and Plan 9 source). That aside, in Go you can also do fixed allocations and manage your own memory pools to avoid the GC. And I would also question how many C programs require real-time behaviour (even the definition of 'real-time' has issues, most things people call 'real-time' aren't).

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.
deleted 14y ago
[deleted]
copx 14y ago
>Your C code looks very unidiomatic to me, but I guess that is relatively a matter of taste (still I don't understand why would somebody use C if they don't like to write code in the 'classic' C style as seen in the original Unix and Plan 9 source). Because we learned a lot about writing more robust and maintainable software since the 1970s. Also the original Unix source code was one thing more than anything: small. Really, really small. Mostly because it did not do much compared to a modern OS. Things like encapsulation, separation of concerns, etc. only become important once the code grows to a certain size. Unfortunately some people think you need at least C++ for that, despite the fact that for example "private" member variables are way less private than incomplete C types. C is old, but that does not mean it is incompatible with modern software development approaches. Or that you have to write code as if your compiler only parsed the first few letters of an identifier. I think C's bad reputation in some circles can be explained by people only ever seeing 1970s style code.
- 2mur 14y ago
  Do you have any resources / books for writing modern C like this or is it all experiential from the trenches?
  - wsc981 14y ago
    I'd say "C programming: A modern approach" (K.N. King) should be a good candidate? Personally I like the book.
  - look_lookatme 14y ago
    I'm interested in this too.
  - copx 14y ago
    >Do you have any resources / books for writing modern C like this No, sorry. >is it all experiential from the trenches? It's mostly about applying general principles of software construction like separation of concerns, encapsulation, robust interfaces, etc.
    - 14y ago
pcwalton 14y ago
Go is a fine language, but I do have a nitpick here: you do not "avoid the GC" by using memory pools. The GC must still trace through the pool when it does run. The more correct thing to say is that you can reduce allocations with memory pools, which make the GC run less often and make it do less work. Furthermore, memory pools compromise safety: if you free a pointer to an object in your memory pool and you accidentally had aliases to that pointer, then you'll get subtle bugs when one of those objects gets reused.
- luriel 14y ago
  In Go you can also just disable the GC if you really want to, but obviously then you have to be more careful.
  - vilya 14y ago
    How well does that work if you're using some thirdparty libraries? Just curious - I haven't used Go yet so don't know what happens there.
- samnardoni 14y ago
  I think the GC in Go only runs when allocations have been made. No allocations = no GC.
  - pcwalton 14y ago
    Yes, but that's only true if you get down to zero allocations. Memory pools reduce allocations, but you cannot get down to zero allocations--even if you somehow managed to convert every allocation site into a memory pool (which basically means not using the standard library), you'd still have to allocate the pool (unless it's stored in static memory, but then your maximum number of allocations is fixed). The only code I've seen that actually had zero allocations in a GC'd language is actually Emscripten-generated code in JS, which is of course not actually JS but C.

by luriel 14y ago

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.

deleted 14y ago

[deleted]

copx 14y ago

>Your C code looks very unidiomatic to me, but I guess that is relatively a matter of taste (still I don't understand why would somebody use C if they don't like to write code in the 'classic' C style as seen in the original Unix and Plan 9 source). Because we learned a lot about writing more robust and maintainable software since the 1970s. Also the original Unix source code was one thing more than anything: small. Really, really small. Mostly because it did not do much compared to a modern OS. Things like encapsulation, separation of concerns, etc. only become important once the code grows to a certain size. Unfortunately some people think you need at least C++ for that, despite the fact that for example "private" member variables are way less private than incomplete C types. C is old, but that does not mean it is incompatible with modern software development approaches. Or that you have to write code as if your compiler only parsed the first few letters of an identifier. I think C's bad reputation in some circles can be explained by people only ever seeing 1970s style code.

2mur 14y ago
Do you have any resources / books for writing modern C like this or is it all experiential from the trenches?
- wsc981 14y ago
  I'd say "C programming: A modern approach" (K.N. King) should be a good candidate? Personally I like the book.
- look_lookatme 14y ago
  I'm interested in this too.
- copx 14y ago
  >Do you have any resources / books for writing modern C like this No, sorry. >is it all experiential from the trenches? It's mostly about applying general principles of software construction like separation of concerns, encapsulation, robust interfaces, etc.
  - 14y ago

pcwalton 14y ago

Go is a fine language, but I do have a nitpick here: you do not "avoid the GC" by using memory pools. The GC must still trace through the pool when it does run. The more correct thing to say is that you can reduce allocations with memory pools, which make the GC run less often and make it do less work. Furthermore, memory pools compromise safety: if you free a pointer to an object in your memory pool and you accidentally had aliases to that pointer, then you'll get subtle bugs when one of those objects gets reused.

luriel 14y ago
In Go you can also just disable the GC if you really want to, but obviously then you have to be more careful.
- vilya 14y ago
  How well does that work if you're using some thirdparty libraries? Just curious - I haven't used Go yet so don't know what happens there.
samnardoni 14y ago
I think the GC in Go only runs when allocations have been made. No allocations = no GC.
- pcwalton 14y ago
  Yes, but that's only true if you get down to zero allocations. Memory pools reduce allocations, but you cannot get down to zero allocations--even if you somehow managed to convert every allocation site into a memory pool (which basically means not using the standard library), you'd still have to allocate the pool (unless it's stored in static memory, but then your maximum number of allocations is fixed). The only code I've seen that actually had zero allocations in a GC'd language is actually Emscripten-generated code in JS, which is of course not actually JS but C.