Interesting comparisons.
However (not slating Go, which I think is excellent), I genuinely think Go is going to go the same way as plan9 eventually. Unfortunately, its predecessor (C) is good enough, much as UNIX was good enough compared to plan9.
However (not slating Go, which I think is excellent), I genuinely think Go is going to go the same way as plan9 eventually. Unfortunately, its predecessor (C) is good enough, much as UNIX was good enough compared to plan9.
These languages also had OS fully implemented on them, just with tiny bits of Assembly to do the very low level stuff, similar to what C would require anyway.
The only advantage of C is that its runtime is so small, that in practice the OS is the C's runtime.
The point you mention is only valid when using entirely static memory, which is a very rare case in real C code (only really used in a few small embedded codebases).
Exactly, and you can also do that in Go to avoid the GC.
Thanks for pointing this out.
This is often a misunderstanding from manual memory management fans. In many cases malloc()/free() also behave non-deterministic.
This is the main reason why for special types of applications, you need to have malloc()/free() implementations specially targeted to the use case at hand.
This is no different from the GC runtimes, which are coded specifically for real time applications, like avionics, for example.
Default platform malloc(3) and free(3) can be a crap indeed, but they are drop-in replaceable with the above at any time, unlike Go GC - if practical testing suggests such replacement is necessary (e.g. Firefox, Facebook servers)
The correct answer would be: depends on the concrete implementation. There are implementations with real-time guarantees.
However, assuming standard desktop OS malloc()/free() the answer is: No. These functions can execute very quickly.. or very slowly, depending on their current internal state. But you can control when they get called, which can be an important difference.
>The point you mention is only valid when using entirely static memory, which is a very rare case in real C code (only really used in a few small embedded codebases).
Depends on what you mean by "entirely static memory". No malloc() calls at all? Yes, that is rare and pretty much limited to the embedded realm I think. Memory pools however are very common in performance critical code.
Anyway, take a look at the OCaml GC. It's simple (probably simpler than glibc's malloc) and very performant particularly if you understand how it works and use it intelligently in your app.
Yes, but only because no major OS manufacturer picked them up as the main system language.
The only way a system language can become mainstream is if it is picked up by an OS vendor that makes it the default system language on their OS.
As for the bare level stuff you describe, real systems like Native Oberon proved this is possible. At ETHZ Native Oberon was used for almost everything an OS is used for.
Sadly no major vendor has got interested on the system, even after some industry attempts tried out by ETHZ.
Not really true, you have direct control over the memory layout of your data structures, and if you want to do really tricky stuff there is also the unsafe package.
Go cleans up and fixes pretty much every issue C had, and improves it in many non-obvious areas, from the syntax to the type system.
And when porting an existing project I'm not surprised if goroutines would come up that often given that they probably don't have any equivalent in the original design.
I suppose that begs the question: if you can built it in the language, should it really be a part of the implementation?
There are also other language features that make it much more usable and that are missing from C, like garbage collection.
I know Rob Pike and Russ Cox have discussed this several times, it might be worth watching this talk by rob about the history of Go's concurrency model you can find here: http://go-lang.cat-v.org/talks/
And Russ Cox's article also about this: http://swtch.com/~rsc/thread/
I'm not sure either covers exactly the reasons why it is a great advantage to make it part of the language, but they are still interesting background.