> It's basically limited to the "network server" use case.

I've been using it to perform research. I also used it to build an X window manager. Neither are remotely close to a "network server" use case. In years past, I would have used C for both projects.

> Just about none of Erlang's reliability mechanisms are present in Go.

I certainly agree that Go shouldn't be viewed as a "better" Erlang, but Go does have green threads with M:N scheduling, which is a significant feature of Erlang. (As argued by Joe Armstrong himself.)

> Go does have green threads with M:N scheduling, which is a significant feature of Erlang.

And Go also has integers, a significant feature of C...

Goroutine's semantics and implementation are nothing like Erlang's processes: the latter are shared-nothing, preempted, monitorable and messageable whereas goroutines are shared-memory cooperative black holes.

Basically, the one and only commonality is that they're mapped M:N on OS threads, which is on par with comparing a wheelie bin and a CAT 797F on grounds that they both have 4 wheels.

> And Go also has integers, a significant feature of C...

So does every other language. Perhaps I need to be more explicit for you: Go does have green threads with M:N scheduling, which is a powerful feature of Erlang that most other languages do not have.

> Basically, the one and only commonality is that they're mapped M:N on OS threads, which is on par with comparing a wheelie bin and a CAT 797F on grounds that they both have 4 wheels.

I'm more convinced by Armstrong's argument [1] (and my own experience). Green threads enable a concurrent style of programming that is not viable in most other programming languages. (See also: Concurrent ML and Concurrent Haskell, although the former is not parallel.)

> Goroutine's semantics and implementation are nothing like Erlang's processes: the latter are shared-nothing, preempted, monitorable and messageable whereas goroutines are shared-memory cooperative black holes.

I have drawn on an important similarity between goroutines and Erlang processes. I did not dispute their differences, although I think your comparison is overly simplistic.

Also, you ignored my rebuttal to your claim that Go's "basically only use case is network servers." Any particular reason why?

[1] - http://www.guug.de/veranstaltungen/ffg2003/papers/ffg2003-ar...

> So does every other language

I dunno. Some obscure languages are float-only. There's one called ECMAscript which I hear gets used in a few places.

I know you're being sarcastic, but Lua [1] is a good couter-example to my generalization as well.

[1] - http://lua-users.org/wiki/NumbersTutorial

I thought about Lua, but figured that javascript would be a more compelling disproof by counterexample (the common wisdom being that "nobody" uses Lua).

edit: yes, I just edited this comment quickly in succession.

Ironically, I use both quite heavily and still made the generalization :P

It's a funny old world.

The JavaScript one has stuck with me because it's another good example of the various camouflaged toe-stubbing obstacles left scattered about the design.

ECMAscript and Go/C's use cases are almost disjoint.

Not always. Sometimes generalisations can be useful.