
Erlang distributed node in Go - geetarista
https://github.com/goerlang/node
======
jallmann
I'm fond of the idea of Erlang as a "systems glue" while using other languages
for performance or safety.

Another example is an Erlang node in OCaml, with a very nice writeup by Ulf
Wiger explaining the reasoning for this kind of architecture:

<http://code.google.com/p/erlocaml/>

~~~
pessimizer
I seem to recall that Sergey Aleynikov was using something like this for his
HFT.

~~~
dr_doom
Chicago's Connamara Systems does this with their HFT framework.

<http://www.connamara.com/solutions-hftframework.html>

------
jerf
There are major semantic disagreements between Go and Erlang, and I would
consider it somewhat dangerous to try to attach them too closely together like
this. For one, the fact that Erlang messages are fundamentally asynchronous
and Go messages synchronous (or buffered, but in Erlang terms, that still
basically synchronous, just with weirder semantics); the inability to
constrain message order coming from Erlang and going into Go is just asking
for deadlocks if your Go servers are anything other than RPC servers (ie, one
message in leads to precisely one message out, guaranteed, and no other
channel communication within that handler). For another, Erlang messages are
untyped and Go channels are typed, not to mention Erlang's type system and
Go's don't really get along either. It's nice to hook them up like this, but I
suspect in practice this is going to prove surprisingly less useful that
hooking the two together across a protocol that carries a lot less semantics
in it, like any existing messaging server. You're going to end up with that
semantic translation layer on the Go side anyhow.

~~~
johnpmayer
I don't think the answer to solving concurrency and parallelism problems lies
entirely in the approach of Go, Erlang, or some other language. Rather,
different layers of approaches seems to be the best solution. Using an
asynchronous, Erlang-style, mailbox & message protocol might better
approximate the network latency costs in the distributed layer of a system,
while synchronized lightweight threads such as in Go might be better suited to
take advantage of single-machine hardware. And that's what this project is
enabling: use Erlang-style coordination, with Go-style optimized worker
processes. It's just providing another option for managing concurrency, and it
might be more suitable than, say, Paxos in many situations.

As far as the type systems go, it's been well established practice that you
use a data interchange format. I thought Erlang used strings for its messages
- surely Go can handle strings as well.

I don't think that you'd necessarily need to have both Erlang and Go running
here - rather, this might be best for writing Go systems that 'act like'
Erlang systems.

~~~
jerf
No, this is about Go functioning as an Erlang node using the Erlang node
communication protocol, and my objection is _precisely_ that this is _not_
using "different layers of approaches"; it is simply smashing one model up
against another _without_ an intervening layer, which is likely to produce
unhappy consequences on both sides. You need an intervening layer between Go
and Erlang because despite their superficial similarities, they are very
different.

You can not do Erlang-style communication with Go processes. The channel-
process id gulf is fairly large (though potentially crossable in Go if you
just throw away a great deal of the style of the language and really jam in
the idea that channels are instead untyped channels for which only one
goroutine will receive, every clause of which is false at the language level
and you will be enforcing it strictly manually), and the synchronous-
asynchronous barrier is effectively uncrossable. If you try to program Erlang
in Go, Go will _deadlock_. Frequently. (Although if you are foolish enough to
try to simulate it with extensive use of buffered channels, it will only
deadlock "frequently" in production, rather than in testing. Buffered channels
are still synchronous, in the end.)

It may be a useful tool in conjunction with an abstraction layer, but the
affordance of using this directly is dangerous.

------
cpeterso
They should have called this project "ergo".

