3 ms·

What would you say about Clojure, then, where one of the big selling points is concurrency?

by ffreire 12y ago

stonemetal 12y ago
Completely different definitions of concurrency. For Clojure what ships in the box as concurrency is multi-thread, single process concurrency(aka built around shared memory). Erlang devs knew that would never scale beyond a single box so they didn't bother going after it. They built single-thread, multi-process concurrency as the core of their concurrency model(share nothing). This means by default Erlang concurrency primitives work beyond a single node, Clojure's don't.
- rdtsc 12y ago
  > They built single-thread, multi-process concurrency as the core of their concurrency model(share nothing). This means by default Erlang concurrency primitives work beyond a single node, Clojure's don't. Well actually Erlang is not single-threaded it is multi-scheduler and multi-process. CPU or OS based threads are used for scheduler and processes (possibly hundreds of thousands of them) run on all of them. Moreover processes are very small memory wise (only a few K) and _most importantly_ have isolated heaps (yes, all while running in the same OS-level process. What you are mentioning there is called "distribution". This is what allows you to send a message to another Erlang process, running on a different machine, different continent and have it look like Pid ! Msg which is exactly how you'd send a message to a local Erlang process as well.
  - matthiasl 12y ago
    > Well actually Erlang is not single-threaded it is multi-scheduler and multi-process. I think the parent and you are talking about separate things. Erlang the language is single threaded. Erlang the language has no concept of threads. That's what I think the parent was referring to, since he writes "concurrency model". The BEAM Erlang VM, on the other hand, uses multiple schedulers and multiple threads, pretty much as you describe. Most people regard that as a characteristic of the VM _implementation_, not the concurrency _model_.
    - rdtsc 12y ago
      > Erlang the language is single threaded. How so? Isn't it closer to multi-threaded with threads having isolated heaps? Can execute lots of spawn(...) statement and now there are multiple threads of execution running.
      - stonemetal 12y ago
        > Can execute lots of spawn(...) statement and now there are multiple threads of execution running. You would end up with lots of processes running. Sure they are implemented differently than OS processes, but that is an implementation detail. If you had an OS that could keep up with Erlang's demand for processes you could implement Erlang processes as system processes and see no difference in behavior. The point was more Erlang processes can talk to processes on another box fairly transparently. Clojure can not, their concurrency primitives are intra process only with no way to reach out to another box without developer effort. If your definition of concurrency is limited to a single process(and call Erlang processes threads) then Erlang and Clojure are about equivalent. If you drop the single process requirement(still calling Erlang processes threads and running multiple copies of the VM) from your definition then Erlang supports more types of concurrency than clojure does. It can support inter process concurrency.
MCRed 12y ago
The JVM is not concurrent. You can't be concurrent on a VM that doesn't support concurrency. People selling clojure as concurrent are the blind leading the blind.

What would you say about Clojure, then, where one of the big selling points is concurrency?

by ffreire 12y ago

What would you say about Clojure, then, where one of the big selling points is concurrency?

Completely different definitions of concurrency. For Clojure what ships in the box as concurrency is multi-thread, single process concurrency(aka built around shared memory). Erlang devs knew that would never scale beyond a single box so they didn't bother going after it. They built single-thread, multi-process concurrency as the core of their concurrency model(share nothing). This means by default Erlang concurrency primitives work beyond a single node, Clojure's don't.

rdtsc 12y ago
> They built single-thread, multi-process concurrency as the core of their concurrency model(share nothing). This means by default Erlang concurrency primitives work beyond a single node, Clojure's don't. Well actually Erlang is not single-threaded it is multi-scheduler and multi-process. CPU or OS based threads are used for scheduler and processes (possibly hundreds of thousands of them) run on all of them. Moreover processes are very small memory wise (only a few K) and _most importantly_ have isolated heaps (yes, all while running in the same OS-level process. What you are mentioning there is called "distribution". This is what allows you to send a message to another Erlang process, running on a different machine, different continent and have it look like Pid ! Msg which is exactly how you'd send a message to a local Erlang process as well.
- matthiasl 12y ago
  > Well actually Erlang is not single-threaded it is multi-scheduler and multi-process. I think the parent and you are talking about separate things. Erlang the language is single threaded. Erlang the language has no concept of threads. That's what I think the parent was referring to, since he writes "concurrency model". The BEAM Erlang VM, on the other hand, uses multiple schedulers and multiple threads, pretty much as you describe. Most people regard that as a characteristic of the VM _implementation_, not the concurrency _model_.
  - rdtsc 12y ago
    > Erlang the language is single threaded. How so? Isn't it closer to multi-threaded with threads having isolated heaps? Can execute lots of spawn(...) statement and now there are multiple threads of execution running.
    - stonemetal 12y ago
      > Can execute lots of spawn(...) statement and now there are multiple threads of execution running. You would end up with lots of processes running. Sure they are implemented differently than OS processes, but that is an implementation detail. If you had an OS that could keep up with Erlang's demand for processes you could implement Erlang processes as system processes and see no difference in behavior. The point was more Erlang processes can talk to processes on another box fairly transparently. Clojure can not, their concurrency primitives are intra process only with no way to reach out to another box without developer effort. If your definition of concurrency is limited to a single process(and call Erlang processes threads) then Erlang and Clojure are about equivalent. If you drop the single process requirement(still calling Erlang processes threads and running multiple copies of the VM) from your definition then Erlang supports more types of concurrency than clojure does. It can support inter process concurrency.

MCRed 12y ago

The JVM is not concurrent. You can't be concurrent on a VM that doesn't support concurrency. People selling clojure as concurrent are the blind leading the blind.