Erlang distributed node in Go | Hacker News Reader

Erlang distributed node in Go

github.com

70 pointsgeetarista8 comments

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/

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

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

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

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.

With what little knowledge I have of erlang, I'd have to agree. However, since go is intended for high concurrency, I wonder if there's some value in creating an OTP style framework. I'd love to see a simple (well, relatively) and robust way to create distributed service in go.

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.

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.

They should have called this project "ergo".

Reply on news.ycombinator.com