5 ms·

does distributed computing correctly Go, Node.js, ever "actors" library you can think of, they are single-threaded-thinker's attempts to scale, and they are no

by j-conn 11y ago

does distributed computing correctly Go, Node.js, ever "actors" library you can think of, they are single-threaded-thinker's attempts to scale, and they are not correct Could you elaborate, or point to a resource comparing the different scaling strategies? What makes the Erlang approach correct?

perishabledave 11y ago
Check out Seven Concurrency Models from Prag Prog. It does a good job of going over concurrency. It doesn't explicitly go over Node.js or Go's concurrency model, but it talks about the pitfalls of concurrency with shared memory and it also goes over the actor model, which is Erlang/Elixir model as well as Scala's Akka. https://pragprog.com/book/pb7con/seven-concurrency-models-in-seven-weeks https://pragprog.com/book/pb7con/seven-concurrency-models-in...
MCRed 11y ago
It really is concurrent and at a fundamental level, eg: it's supported in the VM. The JVM does not support it. It's not a language feature that simulates concurrency and it's not throwing the baby out with the bathwater and just using events (node.js). The book recommended by the other replyer is probably good. I'd also suggest you check out Joe Armstrongs thesis or his ProgPRog book "Learning Erlang". There are many necessary things to do things right. It's not a single feature. Erlang the language, the VM, the OTP platform are a collection of all these choices...
- KirinDave 11y ago
  I understand and appreciate your enthusiasm and excitement over the Erlang vm, but you really shouldn't misrepresent what's possible with the JVM, the Go VM, or even with Node.js. All support parallelism as well as concurrency, and all can do so with an actor paradigm (and predictably, Node's support is the weakest). Erlang's solution is more exciting because it offers a transparent mapping between local and remote code, so long as "transparent mapping" ignores the performance overhead.
  - phamilton 11y ago
    The problem is that there is a leaky abstraction of concurrency in Node and Akka. Anytime you want to do some blocking computation or IO, you put the whole application at risk. This even applies to garbage collection. There's a whole class of things that you shouldn't do in that concurrency model. You also have to be sure that none of the libraries you use are doing these things. (zealots will say "don't do blocking IO in Akka!", which missing the point entirely) Erlang's solution shines (in addition to reasons you cite) because of its efficient scheduler. That's something that you can't have in another language without essentially building Erlang itself.
    - perishabledave 11y ago
      I'm not too familiar with Scala nor Akka, but know that Akka uses the actor model for concurrency. How does it differ from Erlang/Elixir?
      - phamilton 11y ago
        In Akka, multiple actors share a pool of threads. This has a lot of implications: 1. Garbage Collection. Garbage Collection on the JVM is not isolated to actors. One actor causing a lot of memory churn will prompt a garbage collection and prevent all other actors from executing until the Garbage Collector is finished. BEAM (the erlang VM) has per process (aka per actor) garbage collection, so actors will not interfere with each other during garbage collection. 2. Shared Memory. Since the JVM does not provide proper isolation guarantees, actors can in fact access shared memory. Safety in concurrency is accomplished via best practices rather than guaranteed by the VM. The BEAM VM does not allow shared memory. It is impossible for two processes to write to the same memory. While this matches the convention in Akka, it is enforced at the VM level. 3. Scheduler. In Akka, actors are oversubscribed to threads. That's why you can have hundreds of thousands of actors on a single system. The abstraction is great, but the implementation means that calling Thread.sleep is going to tie up a thread. If you do that often enough then all the threads will get tied up and the rest of the actors will be unable to make progress. The BEAM VM handles this scheduling at a much lower level. Calling sleep on an Erlang process is no big deal. While sleep is a contrived example, the effect on the ecosystem is pretty big. Using a blocking HTTP client on Akka is a bad idea. You have to use something like Dispatch or Spray which is essentially callback based (via monadic Futures). In Erlang, you just make the blocking call and the scheduler takes care of it. Since the synchronous code is easier to reason about than asynchronous code, the Erlang solution is simpler, easier to maintain and often more performant. I've spoken with a number of seasoned Scala/Java programmers who basically tell me "Of course you shouldn't do that, just do X or Y". With Erlang, I find there are fewer situations where you need to be an expert to avoid screwing things up.

by j-conn 11y ago

perishabledave 11y ago

Check out Seven Concurrency Models from Prag Prog. It does a good job of going over concurrency. It doesn't explicitly go over Node.js or Go's concurrency model, but it talks about the pitfalls of concurrency with shared memory and it also goes over the actor model, which is Erlang/Elixir model as well as Scala's Akka. https://pragprog.com/book/pb7con/seven-concurrency-models-in-seven-weeks https://pragprog.com/book/pb7con/seven-concurrency-models-in...

MCRed 11y ago

It really is concurrent and at a fundamental level, eg: it's supported in the VM. The JVM does not support it. It's not a language feature that simulates concurrency and it's not throwing the baby out with the bathwater and just using events (node.js). The book recommended by the other replyer is probably good. I'd also suggest you check out Joe Armstrongs thesis or his ProgPRog book "Learning Erlang". There are many necessary things to do things right. It's not a single feature. Erlang the language, the VM, the OTP platform are a collection of all these choices...

KirinDave 11y ago
I understand and appreciate your enthusiasm and excitement over the Erlang vm, but you really shouldn't misrepresent what's possible with the JVM, the Go VM, or even with Node.js. All support parallelism as well as concurrency, and all can do so with an actor paradigm (and predictably, Node's support is the weakest). Erlang's solution is more exciting because it offers a transparent mapping between local and remote code, so long as "transparent mapping" ignores the performance overhead.
- phamilton 11y ago
  The problem is that there is a leaky abstraction of concurrency in Node and Akka. Anytime you want to do some blocking computation or IO, you put the whole application at risk. This even applies to garbage collection. There's a whole class of things that you shouldn't do in that concurrency model. You also have to be sure that none of the libraries you use are doing these things. (zealots will say "don't do blocking IO in Akka!", which missing the point entirely) Erlang's solution shines (in addition to reasons you cite) because of its efficient scheduler. That's something that you can't have in another language without essentially building Erlang itself.
  - perishabledave 11y ago
    I'm not too familiar with Scala nor Akka, but know that Akka uses the actor model for concurrency. How does it differ from Erlang/Elixir?
    - phamilton 11y ago
      In Akka, multiple actors share a pool of threads. This has a lot of implications: 1. Garbage Collection. Garbage Collection on the JVM is not isolated to actors. One actor causing a lot of memory churn will prompt a garbage collection and prevent all other actors from executing until the Garbage Collector is finished. BEAM (the erlang VM) has per process (aka per actor) garbage collection, so actors will not interfere with each other during garbage collection. 2. Shared Memory. Since the JVM does not provide proper isolation guarantees, actors can in fact access shared memory. Safety in concurrency is accomplished via best practices rather than guaranteed by the VM. The BEAM VM does not allow shared memory. It is impossible for two processes to write to the same memory. While this matches the convention in Akka, it is enforced at the VM level. 3. Scheduler. In Akka, actors are oversubscribed to threads. That's why you can have hundreds of thousands of actors on a single system. The abstraction is great, but the implementation means that calling Thread.sleep is going to tie up a thread. If you do that often enough then all the threads will get tied up and the rest of the actors will be unable to make progress. The BEAM VM handles this scheduling at a much lower level. Calling sleep on an Erlang process is no big deal. While sleep is a contrived example, the effect on the ecosystem is pretty big. Using a blocking HTTP client on Akka is a bad idea. You have to use something like Dispatch or Spray which is essentially callback based (via monadic Futures). In Erlang, you just make the blocking call and the scheduler takes care of it. Since the synchronous code is easier to reason about than asynchronous code, the Erlang solution is simpler, easier to maintain and often more performant. I've spoken with a number of seasoned Scala/Java programmers who basically tell me "Of course you shouldn't do that, just do X or Y". With Erlang, I find there are fewer situations where you need to be an expert to avoid screwing things up.