6 ms·

Any time you need to do multiple things at once, erlang (or elixir) is often the best choice. EG: If you have a website and want to serve more than one request

by MCRed 12y ago

Any time you need to do multiple things at once, erlang (or elixir) is often the best choice. EG: If you have a website and want to serve more than one request at at time. If you have multiple people chatting or sending mail, or instant messaging, or voice communicating, erlang is a good choice. If you have a search engine with many people searching, while spiders crawl the web, erlang is a good choice. The only "downside" to erlang is new syntax and that its "slower" on a given node. But this last one isn't really a downside-- you can scale a process to 20 nodes with erlang a whole lot better than, say, node.js or java or go. None of those really support concurrency properly (of the ones who even try.) This makes erlang unique. I think many engineers try to tell themselves that the JVM or node.js or Go can be concurrent, but they are really just making excuses for the fact that the erlang syntax is a bit of a hurdle for getting started. I'm fine with that- it makes a great hiring filter! If someones learned erlang, you know something that makes them better than most of the rest of the programmers out there who are happy to believe rationalizations that let them get away with not learning erlang. (And if you're not thinking about concurrency you're even further behind.)

arms 12y ago
I'm curious why you think Golang doesn't support concurrency properly.
- pessimizer 12y ago
  For comparisons between Go and Erlang, I've been passing this out lately: https://news.ycombinator.com/item?id=7277957 https://news.ycombinator.com/item?id=7277957 edit: the entire thread, not just the OP.
- MCRed 12y ago
  I know go is not concurrent. It doesn't even try.
  - mononcqc 12y ago
    Go is concurrent, and so is clojure (as mentioned in another response of yours). 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.
ffreire 12y ago
What would you say about Clojure, then, where one of the big selling points is concurrency?
- 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_.

by MCRed 12y ago

arms 12y ago

I'm curious why you think Golang doesn't support concurrency properly.

pessimizer 12y ago
For comparisons between Go and Erlang, I've been passing this out lately: https://news.ycombinator.com/item?id=7277957 https://news.ycombinator.com/item?id=7277957 edit: the entire thread, not just the OP.
MCRed 12y ago
I know go is not concurrent. It doesn't even try.
- mononcqc 12y ago
  Go is concurrent, and so is clojure (as mentioned in another response of yours). 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.

ffreire 12y ago

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

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_.