31–32 of 32 posts
Earlier quoted context omitted.
I'm curious why you think Golang doesn't support concurrency properly.
I know go is not concurrent. It doesn't even try.
I don't know what definition of concurrency you're running with, but all of those I heard of, they make it possible to have it there. Not necessarily at the same scale or through the same means, but they definitely make concurrency possible.
Earlier quoted context omitted.
> 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…
> 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.
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.