11 ms·

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

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.

Devilboy 14y ago
The big win for go over c is the goroutines - cheap and easy multithreading built right into the language.
- gouranga 14y ago
  I agree entirely - they are great, but in all the Go I've written (which totals about 50kloc so far as a porting project), I haven't actually used them past anything I would have done with zmq in C.
  - luriel 14y ago
    Goroutines are great, but I'm not convinced they are the greatest advantage over C. 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.
- jamwt 14y ago
  zeromq or coroutine libraries like libtask (by a go author!) have greatly reduced this advantage.
  - gouranga 14y ago
    libtask looks really cool. Thanks for posting. I suppose that begs the question: if you can built it in the language, should it really be a part of the implementation?
    - luriel 14y ago
      Plan 9's libthread ( http://man.cat-v.org/plan_9/2/thread http://man.cat-v.org/plan_9/2/thread ) provides similar CSP-style concurrency to Go. Yet, the authors, after using it for many years, and after having used and built systems where it was part of the language (eg., Inferno/Limbo) decided it was important enough to make it part of the language for it to be usable. 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/ http://go-lang.cat-v.org/talks/ And Russ Cox's article also about this: http://swtch.com/~rsc/thread/ 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.
      - gouranga 14y ago
        Thanks for the information - I will have a good read this evening :)
nux6 14y ago
The devil is in details. Go is great for hi-level or simple stuff like that, but is not really usable for system programming. If things are a bit more complicated, the go runtime stays in the way. For those problems, after a while, the bare metal support was removed from the language completely...
- pjmlp 14y ago
  Ever heard of Oberon, Modula-2 and Modula-3? 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.
  - mkup 14y ago
    It's not the only advantage. Another, more important advantage of C and C++ over Go is a lack of stop-the-world garbage collection (and predictable memory usage under high load).
    - rwmj 14y ago
      You can predict the time that malloc(3) and free(3) take to run? You know they are backed by very complex data structures that need to manipulated and iterated over? 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).
      - luriel 14y ago
        > The point you mention is only valid when using entirely static memory Exactly, and you can also do that in Go to avoid the GC.
      - pjmlp 14y ago
        > You can predict the time that malloc(3) and free(3) take to run? 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.
thdn 14y ago
Even the pet looks similar hehehe :P
- jff 14y ago
  Could be because they were both created by the same person.

Devilboy 14y ago

The big win for go over c is the goroutines - cheap and easy multithreading built right into the language.

gouranga 14y ago
I agree entirely - they are great, but in all the Go I've written (which totals about 50kloc so far as a porting project), I haven't actually used them past anything I would have done with zmq in C.
- luriel 14y ago
  Goroutines are great, but I'm not convinced they are the greatest advantage over C. 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.
jamwt 14y ago
zeromq or coroutine libraries like libtask (by a go author!) have greatly reduced this advantage.
- gouranga 14y ago
  libtask looks really cool. Thanks for posting. I suppose that begs the question: if you can built it in the language, should it really be a part of the implementation?
  - luriel 14y ago
    Plan 9's libthread ( http://man.cat-v.org/plan_9/2/thread http://man.cat-v.org/plan_9/2/thread ) provides similar CSP-style concurrency to Go. Yet, the authors, after using it for many years, and after having used and built systems where it was part of the language (eg., Inferno/Limbo) decided it was important enough to make it part of the language for it to be usable. 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/ http://go-lang.cat-v.org/talks/ And Russ Cox's article also about this: http://swtch.com/~rsc/thread/ 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.
    - gouranga 14y ago
      Thanks for the information - I will have a good read this evening :)

nux6 14y ago

The devil is in details. Go is great for hi-level or simple stuff like that, but is not really usable for system programming. If things are a bit more complicated, the go runtime stays in the way. For those problems, after a while, the bare metal support was removed from the language completely...

pjmlp 14y ago
Ever heard of Oberon, Modula-2 and Modula-3? 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.
- mkup 14y ago
  It's not the only advantage. Another, more important advantage of C and C++ over Go is a lack of stop-the-world garbage collection (and predictable memory usage under high load).
  - rwmj 14y ago
    You can predict the time that malloc(3) and free(3) take to run? You know they are backed by very complex data structures that need to manipulated and iterated over? 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).
    - luriel 14y ago
      > The point you mention is only valid when using entirely static memory Exactly, and you can also do that in Go to avoid the GC.
    - pjmlp 14y ago
      > You can predict the time that malloc(3) and free(3) take to run? 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.

thdn 14y ago

Even the pet looks similar hehehe :P

jff 14y ago
Could be because they were both created by the same person.