4 ms·

> Anytime you want to do some blocking computation or IO, you put the whole application at risk. It is true that you should not do this, and it's a fair point

> Anytime you want to do some blocking computation or IO, you put the whole application at risk. It is true that you should not do this, and it's a fair point. Of course, you don't do it with Erlang either! Erlang carefully takes all file I/O out of their actor model and has it so that one (and only one) process can interact with a file handle. Operations to this have to be serialized by the actor. Since there is only one implementation of I/O and it's non-blocking, this works fine, but if your application is an actor pipeline you run exactly the same risk as your mailbox overflows. Needham's Duality is real. And naturally that ignores the fact that JVM concurrency and parallelism can handle that outcome perfectly well (and in fact Akka appeals to these primitives). It's absurd to suggest that java.util.concurrent doesn't have great tools for parallel anything, let alone parallel I/O. Golang, by the way, doesn't have this restriction. The runtime supports non-blocking, parallel-friendly I/O from the ground up. And as for Node.js, well the general abstraction here is the most parallel of all. I'm not a huge fan of it and I agree it's a bit leaky, but Node's cluster stuff is serviceable and used by many. You cannot argue the actor model is essential, threadpools and actors ultimately model the same process and as Go has shown can do so with similar sharing semantics. Finally, Erlang's scheduler is not black magic nor an arcane work of wisdom. It uses well-known, well documented principles and techniques. Quite frankly, its not the secret sauce of Erlang. Erlang's secret sauce is the HUGE some of very good code for building a distributed system with all the robust goodness that OTP provides. Erlang's great, Elixir is interesting (albeit it took one stinky old syntax and exchanged it for another stinky syntax). I wanted to reply to that prior post and talk to why Erlang has a magical recipe for distributed code, not parallel code. Quite frankly, Erlang's parallelism story only makes sense in the context of its decision to make remote and local execution indistinguishable at the call site.

phamilton 12y ago
In the context of sharing IO, Erlang does have the same problems. I was however referring to IO in the sense of "I'm going to block until I get a response." And not have to deal with callback shenanigans (be it futures or callbacks). Golang does solve these issues fairly well except for GC issues (which I've heard have gotten better).
- KirinDave 12y ago
  > I was however referring to IO in the sense of "I'm going to block until I get a response." And not have to deal with callback shenanigans (be it futures or callbacks). Callbacks and futures are very different modeling techniques and I'm not sure why you'd suggest they're inherently inferior. They have their uses just like the Actor model. People obsess on the existence of blocking I/O (proponents of Node.js do this too) and I find it strange that this is still a subject of conversation. It's by and large a solved problem. > Golang does solve these issues fairly well except for GC issues (which I've heard have gotten better). Golang's GC issues were no to much about GOMAXPROCs as just needing a really good optimization pass. As a younger language, it's unsurprising it needs some time to reach production readiness. Erlang has the benefit of many years of testing in anger.

phamilton 12y ago

In the context of sharing IO, Erlang does have the same problems. I was however referring to IO in the sense of "I'm going to block until I get a response." And not have to deal with callback shenanigans (be it futures or callbacks). Golang does solve these issues fairly well except for GC issues (which I've heard have gotten better).

KirinDave 12y ago
> I was however referring to IO in the sense of "I'm going to block until I get a response." And not have to deal with callback shenanigans (be it futures or callbacks). Callbacks and futures are very different modeling techniques and I'm not sure why you'd suggest they're inherently inferior. They have their uses just like the Actor model. People obsess on the existence of blocking I/O (proponents of Node.js do this too) and I find it strange that this is still a subject of conversation. It's by and large a solved problem. > Golang does solve these issues fairly well except for GC issues (which I've heard have gotten better). Golang's GC issues were no to much about GOMAXPROCs as just needing a really good optimization pass. As a younger language, it's unsurprising it needs some time to reach production readiness. Erlang has the benefit of many years of testing in anger.