Go vs Erlang
Peter Kleiweg
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?
--
Peter Kleiweg
http://pkleiweg.home.xs4all.nl/
Ian Lance Taylor
> 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
Jeremy Wall
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.
Andrew Francis
On Nov 1, 5:32 pm, Peter Kleiweg <pklei...@xs4all.nl> wrote:
> I have been reading into some Erlang documentation. I think the
> model of concurrency in Go and Erlang are quite similar.
based on synchronous channels/rendezvous semantics. Erlang is based on
an actor model (asynchronous messages with mailboxes). Erlang is a
functional language. Go isn't.
Cheers,
Andrew
Robert Johnstone
While there are certainly some significant differences, if one sticks
with go routines and channels, the concurrency models are not that far
apart. An good implementation of netchan could further bridge the
gap.
A good deal of Erlang's well reserved reputation for reliability is
due OTP. I'm not certain how easily these libraries could be ported
to go. However, the main difference is the use of tagged, untyped
tuples as message instead of Go's more strongly typed messages.
Robert
David Leimbach
On Nov 1, 3:10 pm, Ian Lance Taylor <i...@google.com> wrote:
processes is probably an interesting comparison. Erlang not letting
you mutate variables once their bound might mean that behind the
scenes it's not really always having to copy memory as much as it
seems it could be. I don't know enough about the guts to comment.
In Erlang you *ONLY* get asynchronous message sends, but you also get
timeout clauses in receive statements when you expect a reply.
Go and Erlang are similar but different :-).
I feel like Erlang's a bit higher level than Go, but that's mainly due
to their pretty impressive runtime that allows you to compile and hot-
replace code while the app is running. You can have two versions of a
code module in memory at once and swap it out when the time is right.
Go is very very young compared to Erlang too, so let's see where Go
goes :-).
>
> Ian
Jeremy Wall
<r.w.jo...@gmail.com> wrote:
> Hello,
>
> While there are certainly some significant differences, if one sticks
> with go routines and channels, the concurrency models are not that far
> apart. An good implementation of netchan could further bridge the
> gap.
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.
Aram Hăvărneanu
> 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
Jeremy Wall
Right. All of this combines to make erlang much more different from Go than
you might initially expect.
>
> --
> Aram Hăvărneanu
>
JLarky
> due OTP. I'm not certain how easily these libraries could be ported
> to go.
to follow. I don't sure in terminology but it's more like pattern or
prototype when you have to build you system implementing some standard
behaviors as server, FSM, supervisor and so on. Everything OTP related
done in plain Erlang and I think can be translated in Go. But...
> tuples as message instead of Go's more strongly typed messages.
Erlang, so you can handle like every erlang term as request and have
reply as any term, when in Go more convenient way will be typed
channels.
For me Erlang way is more general, and Go one is more, I don't know,
optimized?
Taru Karttunen
> > A good deal of Erlang's well reserved reputation for reliability is
> > due OTP. I'm not certain how easily these libraries could be ported
> > to go.
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
Jesse McNelis
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
JLarky
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:
Matthew Sackman
> It's also unordered, packages may arrive in any order,
( 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
Matthew Sackman
> > 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.
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
Jeremy Wall
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.
>