5 ms·
I've never really understood the desire to compare Go and Erlang. They serve radically different purposes. The only thing they share are processes/goroutines (o
by zaphar 12y ago
I've never really understood the desire to compare Go and Erlang. They serve radically different purposes. The only thing they share are processes/goroutines (or greenlets, green threads, fibers, whatever you want to call them). A cheap small footprint concurrency primitive.
Go was created to make buildng a single server (in the software not hardware sense) easier.
Erlang was created to create systems for managing a lot of servers with a complicated dependency hierarchy.
Go doesn't have OTP and a fault tolerant runtime because Google has all that stuff at a separate layer in their datacenters and the Go engineers didn't feel a need to solve that problem. They wanted to solve the problem of still having to build http servers in C++ for performance and all the attendant annoyances that brings.
If I were going to build a massive distributed system today I'd use the Erlang runtime to manage the overall system in a fault tolerant way and I'd use Go to build the components.
They complement themselves well but they don't really replace each other.
- mratzloff 12y agoA cogent response. I didn't get far into the thread because it seemed like no one had any significant experience in Go and therefore they were not qualified to debate each language's relative merits. Maybe it improved after the point I stopped.
- zaphar 12y agoIt's more cogent I think because I'm a fan of both languages and have done non trivial work in both. The thread was short on people with both experience in Go and with knowledge of the motivations for Go.
- regularfry 12y agoIt's all about the reader, and very little about the languages themselves. Erlang and Go are candidate "next language to learn" entries for a lot of people at the moment: Go because it's new(ish), it's shiny, but it's stable enough and there are enough success stories about to convince PHB's that it's not a risk; and Erlang, because ZOMG UPTIME. They appear together because they superficially share enough that someone interested in solving problems with one is likely to be doing something that the other can take a reasonable stab at, even if it's not in the sweet spot. And they both sell themselves hard on the "concurrency" angle, despite not necessarily meaning quite the same thing when they say it.
- planckscnst 12y agoThe packaging and explicit function exporting are also quite similar. The absense of "typical/popular" (c++ as opposed to smalltalk) style of OOP is also shared. When I began learning Erlang, I immediately understood why people compared them: I found them quite similar to each other (much more simllar to each other than either to c++, python, ruby, perl, lisp, lua, etc) as well.
- eternalban 12y ago"Go doesn't have OTP" It should/will.
- dozzie 12y agoIt can't because of lack of forced exits, monitors and links.