4 ms·

The Erlang ecosystem is centered around creating tools for dealing with concurrency. Concurrent programming concerns itself with trying to represent a certain s

The Erlang ecosystem is centered around creating tools for dealing with concurrency. Concurrent programming concerns itself with trying to represent a certain set of semantics in which a program must deal with multiple requests that overlap in time. A concurrent program could ultimately be executed on a single logical processor via some form of time sharing. It just has to be able to deal with multiple requests which can overlap in time rather than neatly coming one after the other. derefr's comment that is a sibling to yours is a good example of pointing out Erlang's strengths when it comes to expressing concurrent semantics (notice nowhere in derefr's response is there any talk of performance). However, Erlang, as you have correctly pointed out, is not very good if you only care about parallelism. Parallelism is not concerned with semantics, but performance; it concerns itself with trying to make a given computation faster by using multiple physical hardware resources but maintaining the same semantics as a hypothetical non-parallel version. Your argument is a cogent one for why Erlang is not great if you only care about parallelism. Being able to scale a program to use 20 cores is no good if the same program written in another language could beat the pants off that program using just one core. However, that is an independent concern from concurrency.

tiffanyh 5y ago
Would you say then that Erlang has low latency and low standard deviation of how fast it will respond to any request under any amount of load. It might not have the highest transactions per second, but for those transactions it completes - it’ll do it fast and with the same low latency. There’s other languages that can perform more transaction per second but as load increases, their latency and standard deviations grows exponentially. (This is seen in the stressgrid benchmarks).
- dwohnitmok 5y ago
  I'm not the best person to ask about Erlang's performance characteristics. I know them in broad strokes from light reading about the BEAM VM but I've never written any Erlang that has made it out to production, only for the smallest of hobby projects. So I don't know, e.g. what the P99 latency of a given Erlang program might be. That being said, my point was that concurrency is an independent topic from runtime performance (including latency), which is the domain of parallelism. Erlang's big selling point is it makes it possible to write concurrent programs whose functionality (not performance) would require oodles and oodles of code and discipline in some other languages. EDIT: On reflection I do think if what you're talking is catastrophic latency overruns caused by cascading queuing failures then Erlang can indeed help make it easier to avoid those pitfalls.
- pdimitar 5y ago
  > Would you say then that Erlang has low latency and low standard deviation of how fast it will respond to any request under any amount of load. Yes, that's exactly correct. Erlang/Elixir server apps aren't the fastest around but their latency is very predictable and they remain responsive under load, unlike programs written is most other languages. That's the main selling point of the BEAM VM.
  - hinkley 5y ago
    I'm curious how weird that's going to get with the JIT, as the variability in processing time becomes more variable.
    - pdimitar 5y ago
      It's likely there will be some more wildly varying latency figures until all hot paths are JIT-ted, kind of like it is with Java.
      - dmpk2k 5y ago
        All code is compiled to its final machine-code form at start-up, so there's no warm-up. It's closer to an AOT compiler than most JITs.
        pdimitar 5y ago
        Thanks for the correction, I was operating under a false assumption. Good to know!
hinkley 5y ago
> Your argument is a cogent one for why Erlang is not great if you only care about parallelism. Being able to scale a program to use 20 cores is no good if the same program written in another language could beat the pants off that program using just one core. However, that is an independent concern from concurrency. I think this sells it short. Serious software has to cross machine boundaries at some point. There are pieces of code and styles of writing them that work really well on one core. They may also do okay on one machine. But once you have to go to two machines they become a huge burden. A liability. Part of the way people like IBM used to make tons of money was off of people who had software that could not cross the one machine threshold. They sold really, really big machines. They sold unobtanium that let you continue to scale your one machine vertically. Like $20,000 hard drives (1990's dollars) that were essentially battery backed RAM, meant for things like putting your WAL on to speed up transaction commits per second. Speed doesn't mean much if it's taking you in the wrong direction.

tiffanyh 5y ago

Would you say then that Erlang has low latency and low standard deviation of how fast it will respond to any request under any amount of load. It might not have the highest transactions per second, but for those transactions it completes - it’ll do it fast and with the same low latency. There’s other languages that can perform more transaction per second but as load increases, their latency and standard deviations grows exponentially. (This is seen in the stressgrid benchmarks).

dwohnitmok 5y ago
I'm not the best person to ask about Erlang's performance characteristics. I know them in broad strokes from light reading about the BEAM VM but I've never written any Erlang that has made it out to production, only for the smallest of hobby projects. So I don't know, e.g. what the P99 latency of a given Erlang program might be. That being said, my point was that concurrency is an independent topic from runtime performance (including latency), which is the domain of parallelism. Erlang's big selling point is it makes it possible to write concurrent programs whose functionality (not performance) would require oodles and oodles of code and discipline in some other languages. EDIT: On reflection I do think if what you're talking is catastrophic latency overruns caused by cascading queuing failures then Erlang can indeed help make it easier to avoid those pitfalls.
pdimitar 5y ago
> Would you say then that Erlang has low latency and low standard deviation of how fast it will respond to any request under any amount of load. Yes, that's exactly correct. Erlang/Elixir server apps aren't the fastest around but their latency is very predictable and they remain responsive under load, unlike programs written is most other languages. That's the main selling point of the BEAM VM.
- hinkley 5y ago
  I'm curious how weird that's going to get with the JIT, as the variability in processing time becomes more variable.
  - pdimitar 5y ago
    It's likely there will be some more wildly varying latency figures until all hot paths are JIT-ted, kind of like it is with Java.
    - dmpk2k 5y ago
      All code is compiled to its final machine-code form at start-up, so there's no warm-up. It's closer to an AOT compiler than most JITs.
      - pdimitar 5y ago
        Thanks for the correction, I was operating under a false assumption. Good to know!

hinkley 5y ago

> Your argument is a cogent one for why Erlang is not great if you only care about parallelism. Being able to scale a program to use 20 cores is no good if the same program written in another language could beat the pants off that program using just one core. However, that is an independent concern from concurrency. I think this sells it short. Serious software has to cross machine boundaries at some point. There are pieces of code and styles of writing them that work really well on one core. They may also do okay on one machine. But once you have to go to two machines they become a huge burden. A liability. Part of the way people like IBM used to make tons of money was off of people who had software that could not cross the one machine threshold. They sold really, really big machines. They sold unobtanium that let you continue to scale your one machine vertically. Like $20,000 hard drives (1990's dollars) that were essentially battery backed RAM, meant for things like putting your WAL on to speed up transaction commits per second. Speed doesn't mean much if it's taking you in the wrong direction.