Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's been a few years since I've done any Erlang work, but there's a couple of places of the top of my head where Erlang take fault tolerance to a higher level as compared to Go.

While Go's goroutines give you similar sort of concurrency, they don't work in the distributed sense in the same way as Erlang. Go let's me fiddle around with the goroutines on my computer, but that's it. With Erlang, I can natively talk to the routines on any of the computers in my cluster. Just prepend a function call with an IP address and I can call a function on a completely different computer. While you could emulate this with XMLRPC or JSON, it's not backed into the language and it's not treated as a first class function the way it is in Erlang.

Also, Erlang's basic libraries were built with hot code loading in mind. You shouldn't have to stop and restart your software just to fix a bug. Now, I've seen discussion on how it's possible to do this with Go, but Erlang keeps the idea so pervasive that almost every beginner's guide include how to do it. As a side note, being a dynamic language has some advantages with hot code loading, though this can be a matter of taste.



The Netchan project I think showed how that particular limitation -- distributed goroutines -- will be overcome in time and, i think, built in to the language runtime.

This is just idle speculation but it seemed to me, reading the mailing list ages ago when this was discussed, that netchan worked in many use cases, but not others, and it just was not the right time in the development of the language to be distracted by a tertiary feature like that. Now, I could be mis-reading the whole thing and maybe it will never be a language feature. But if I were a betting man...


The gocircuit project is trying to make distributed goroutines practical but it seems a little rough: http://www.gocircuit.org/




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: