5 ms·
> 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 rem
by burntsushi 14y ago
> 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.)
- masklinn 14y ago> 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.
- burntsushi 14y ago> 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-armstrong.pdf http://www.guug.de/veranstaltungen/ffg2003/papers/ffg2003-ar...
- jacques_chester 14y ago> 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.
- gcr 14y agoECMAscript and Go/C's use cases are almost disjoint.
- jacques_chester 14y ago> every other language Generalisations are excellent sarcasm-bait.
- sjwright 14y agoNot always. Sometimes generalisations can be useful.
- burntsushi 14y agoI 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 http://lua-users.org/wiki/NumbersTutorial
- jacques_chester 14y agoI 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.
- burntsushi 14y agoIronically, I use both quite heavily and still made the generalization :P