Erlang's primary objective was to be a reliable, fault-tolerant,
system, distributed over possible not quite reliable machines
and network connections.
Does Go aim to offer that same kind or reliability and
fault-tolerance? Is it a serious competitor to Erlang?
--
Peter Kleiweg
http://pkleiweg.home.xs4all.nl/
> I have been reading into some Erlang documentation. I think the
> model of concurrency in Go and Erlang are quite similar.
>
> Erlang's primary objective was to be a reliable, fault-tolerant,
> system, distributed over possible not quite reliable machines
> and network connections.
>
> Does Go aim to offer that same kind or reliability and
> fault-tolerance? Is it a serious competitor to Erlang?
I would say that there are significant differences between the Go and
Erlang concurrency models. Go is a shared memory model and Erlang is
not. Erlang is designed to run across a cluster of machines connected
on a network. Go is designed to run on a multicore processor.
Ian
On Tue, Nov 1, 2011 at 4:32 PM, Peter Kleiweg <pkle...@xs4all.nl> wrote:
>
> I have been reading into some Erlang documentation. I think the
> model of concurrency in Go and Erlang are quite similar.
>
> Erlang's primary objective was to be a reliable, fault-tolerant,
> system, distributed over possible not quite reliable machines
> and network connections.
>
> Does Go aim to offer that same kind or reliability and
> fault-tolerance? Is it a serious competitor to Erlang?
Go is similar in that is makes it easy to spin up goroutines and send messages to them.
But in a lot of other ways the two are very different beasts. Erlang's runtime and the patterns
codified for you in OTP are where you get that reputation for reliability and fault-tolerance.
Erlangs message boxes and Go's channels are not really the same thing and thinking of them
as the same thing will cause you problems later. The same with goroutines and erlangs processes.
That said I think you could use Go as the foundation for building some very reliable and fault-tolerant
systems.
While this is true a large difference is that erlang's message passing
model is asynchronous by default while Go's might be synchronous or
not depending on how you constructed the channel and how full the
channels buffer is if it's buffered. Most Go code I see seems to be
synchronous.
It's also unordered, packages may arrive in any order, and they not
guaranteed to deliver at all. There's also the subtle, but important
distinction that mailboxes are like files, while channels are like
file descriptors.
--
Aram Hăvărneanu
Right. All of this combines to make erlang much more different from Go than
you might initially expect.
>
> --
> Aram Hăvărneanu
>
They cannot be really ported to Go at the moment.
Consider e.g. a supervisor process that wants to kill a buggy child in
an infinite loop or blocking infinitely on IO. This seems impossible to do
in Go at the moment (goroutines cannot be killed from outside if they do
not want to be killed).
- Taru Karttunen
There is a reason for that. Channel communication between goroutines is
always successful in Go. Unlike Erlang's processes, goroutines aren't a
fault tolerant system, a goroutine that unexpectedly panics is a bug.
Fault tolerance in Go is done at the operating system process level
since this has traditionally been where fault tolerance has been in unix
systems and this is where the tools exist to do this kind of monitoring.
- jessta
You right, It's very valid point. And I don't really see how we can wrap goroutine in a way that it will respond to messages like 'terminate'. And one more thing that lack in Go is link mechanism when process can get message when another process dies, because it's done by internal functions.So question now is can we create something like processes in Erlang? We need Pids, terminate, trap_exit, links and monitors, in process state (get, put). At least as I can see it from source code of OTP related modules:
( I assume you mean "messages", not "packages". If you do mean
"packages" then I'm confused, and please ignore the following! )
That's not quite true. The *only* ordering guarantee you have is that if
A sends m to B and then A sends m' to B then B's mailbox will contain m
ahead of m' (assuming B receives both m and m'). Like much of the
internet, hops between Erlang processes do not obey Euclidean geometry.
Matthew
You can quite easily build monitors in Go, and once you have monitors,
you can make links too. Yes, you end up having to build a "spawn"
function which essentially wraps "go", and ensures than once the fun's
done, it fires off all the monitors, but it's not really that hard to
do.
> > So question now is can we create something like processes in Erlang? We
> > need Pids, terminate, trap_exit, links and monitors, in process state (get,
> > put). At least as I can see it from source code of OTP related modules:
> > https://github.com/erlang/otp/blob/master/lib/stdlib/src/gen.erl
> > https://github.com/erlang/otp/blob/master/lib/stdlib/src/supervisor.erl
In Erlang, processes are named but mailboxes and processes are
really the same thing. In Go, you can't name processes, but you can name
channels so you can start to go in the same direction that way. What
turns out to be rather fiddly is getting the whole system to bootstrap
up - it's things like registries and such that end up being quite fiddly
to do. - Yes, I am actually working on some of these ideas right now.
Matthew
My own playground for OTP inspired ideas for go live here:
http://code.google.com/p/gosup/
It's a total toy and not really all that useful but I had fun playing with it.
>