I like Go but it's not a replacement or even just competition for C. Garbage collection alone ensures that.
C is for low-level code, where you usually want deterministic, real-time behavior. Go cannot deliver that because of its GC.
You can certainly write web server software in Go (what Go was designed for), but could you write an "AAA" video game in it? Or a mission critical embedded system with real-time requirements?
Also, the author's portrayal of C is misleading. If you have 'naked' malloc() calls all over your code you are doing something wrong. Much C code never calls malloc() or follows the "no allocation after initialization" principle.
If you write C like Python you will run into problems. In C you do not wildly allocate objects on the heap all across the program. E.g. in my current program almost everything comes out of memory pools. E.g.
Object* object = ObjectNew();
..and if I forgot to release it I would know quickly because any "memory leak" would cause the (pre-allocated, fixed size) memory pool to run out of free slots. In C you should manage memory in a systematic fashion.
I think the C standard library should be seen as the very foundation of a program, something you use to build the abstractions which solve the problem, not something you use directly to solve the problem. People often warn about the dangers of strcpy() (an the author uses it). I never use it except at the lowest levels. At the high level robust C code looks more like this:
ObjectSetName(object, newName);
than this
strcpy(object->name, newName);
..the difference is that ObjectSetName() can internally guard against overflow and that the concrete details of the object data structure remain hidden and thus later code changes are easier. It is a very common C idiom to use incomplete types and such functions to achieve a very high level of encapsulation.
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).
>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.
>Because we learned a lot about writing more robust and maintainable software since the 1970s.
Plan 9 wasn't written in the 70s. OpenBSD is another example, probably a better example given that their sshd is far more important, and running on far more machines than anything you've ever written. So it seems rather disingenuous to suggest that the authors of such software are wrong for writing simple, concise, effective code instead of your bizarre vision of C.
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.
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.
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.
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.
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.
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) which then allow them to be used for hard real-time systems.
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.
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.
The GC in Go 1 is a bit smarter than it used to be, and it is going to be even smarter in Go 1.1, this things take time, and the current GC works quite well for most people. Also Go gives you control over memory layout, which allows you to avoid some GC issues that are much more difficult in languages like Java.
You can avoid those things in Java as well, by adjusting settings. Adjusting eden and generation sizes with generational GC is a bit of an art for all but the simple cases.
C is for low-level code, where you usually want deterministic, real-time behavior. Go cannot deliver that because of its GC.
You can certainly write web server software in Go (what Go was designed for), but could you write an "AAA" video game in it? Or a mission critical embedded system with real-time requirements?
Also, the author's portrayal of C is misleading. If you have 'naked' malloc() calls all over your code you are doing something wrong. Much C code never calls malloc() or follows the "no allocation after initialization" principle.
If you write C like Python you will run into problems. In C you do not wildly allocate objects on the heap all across the program. E.g. in my current program almost everything comes out of memory pools. E.g.
Object* object = ObjectNew();
..and if I forgot to release it I would know quickly because any "memory leak" would cause the (pre-allocated, fixed size) memory pool to run out of free slots. In C you should manage memory in a systematic fashion.
I think the C standard library should be seen as the very foundation of a program, something you use to build the abstractions which solve the problem, not something you use directly to solve the problem. People often warn about the dangers of strcpy() (an the author uses it). I never use it except at the lowest levels. At the high level robust C code looks more like this:
ObjectSetName(object, newName);
than this
strcpy(object->name, newName);
..the difference is that ObjectSetName() can internally guard against overflow and that the concrete details of the object data structure remain hidden and thus later code changes are easier. It is a very common C idiom to use incomplete types and such functions to achieve a very high level of encapsulation.