4 ms·

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

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 14y ago
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.

jerf 14y ago

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.