4 ms·

Thanks. I suspected run-time constraints might be a reason so that makes a lot of sense. > Notably, Erlang's model, while it has excellent properties, falls d

Thanks. I suspected run-time constraints might be a reason so that makes a lot of sense. > Notably, Erlang's model, while it has excellent properties, falls down on all three of these other requirements. Being nitpicky, but I'd argue Erlang only falls down on speed where it's computationally bound. Where it's IO bound (e.g. a prototypical chat server) Erlang has excellent speed characteristics - where speed is measured in concurrency and latency. But I absolutely get that's not the interpretation of "speed" you meant. Appreciate the explanation.

steveklabnik 7y ago
While it is true that I'm mostly talking about computation speed, that's not the only thing. It is true that Erlang is good at this, but I'd like to see some real numbers here. In benchmarks, this is almost never the case. For example, if you take a look at techempower's plaintext benchmark, which should purely be about IO: https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=plaintext https://www.techempower.com/benchmarks/#section=data-r18&hw=... Phoenix, which is in Elixir, does 2.7% of the requests of the Rust frameworks. Chicago Boss, in Erlang, does 0.2%. Is this a realistic benchmark? I don't know; I can't say if the code for either of these implementation is good or not. But if it's a silly error, I think it would be good for Elixir/Erlang advocates to fix this. Early Rust implementations had extremely poor showings too. I tend to think of Erlang as being extremely reliable, with acceptable performance, rather than being the fastest IO language in the West.
- di4na 7y ago
  As an admin of the elixir slack, i have to handle that one a lot. It is not really realistic at all no. But mostly because the benchmark is not realistic of a production load. That said we should do better. The main reason it is not fixed is that the few members of the community that tried to fix it had a really bad experience interacting with the repo and getting feedback of impact and simply lost interest. And we have not have people motivated enough so far because they do not really care about the benchmark. Ofc it matters to people that are not in the community but well... That said, yes we would never be close to Rust anyway (probably) but we could probably have a far better standard deviation than Rust. Something that tend to matter in production a lot but people forget reading benchmark is the spread of the response time vs the average one. We should also perform better in a noisy environment like the "cloud" one. There are hopes that the recent EEF marketing group could help find volunteers or finance someone to fix it.
  - steveklabnik 7y ago
    Yep, that makes perfect sense. I've had good experiences contributing, but it can be tough... It's also 100% true that benchmarks are not representative of production loads. Sadly, it's also 100% true that programmers make decisions based on benchmarks that aren't representative of production loads. It's a real catch-22 situation.
adwn 7y ago
> Being nitpicky, but I'd argue Erlang only falls down on speed where it's computationally bound. Where it's IO bound (e.g. a prototypical chat server) Erlang has excellent speed characteristics - where speed is measured in concurrency and latency. At the scale where asynchronous IO becomes interesting, speed is computationally bound. Think maintaining tens of thousands of TCP connections. You can either spawn a single OS thread for each connection, which gets prohibitively expensive with regards to memory consumption, or you can use asynchronous IO and have a couple of native worker threads, approx. 1 per CPU core. If Erlang can handle, say, tens of thousands of TCP connections with one Erlang thread/actor per connection, then only because it is using an implementation of asynchronous IO in the background.
- spinningslate 7y ago
  > If Erlang can handle, say, tens of thousands of TCP connections with one Erlang thread/actor per connection, then only because it is using an implementation of asynchronous IO in the background. Yes, it can. That's one of the BEAM's key strengths (the Erlang VM). It presents a simple, uniform concurrency abstraction - the process - to developers. Note these are application-level processes, not OS level. They're very lightweight and it's possible to spin up tens of thousands on a single machine. The VM multiplexes user processes over the underlying hardware (threads/cores). More here [0]. [0] https://stackoverflow.com/questions/2708033/technically-why-are-processes-in-erlang-more-efficient-than-os-threads https://stackoverflow.com/questions/2708033/technically-why-...
  - Manishearth 7y ago
    We used to have M:N threading in Rust's runtime -- this is one other way to achieve what we wanted. It imposed a cost on all programs, including those which weren't using it, and iirc it didn't fit well and wasn't flexible enough (I'm not sure of this) and it got removed. Async/await/futures with library level scheduling is basically the only way to get the benefits of application threads in rust without such downsides.
    - dboreham 7y ago

steveklabnik 7y ago

While it is true that I'm mostly talking about computation speed, that's not the only thing. It is true that Erlang is good at this, but I'd like to see some real numbers here. In benchmarks, this is almost never the case. For example, if you take a look at techempower's plaintext benchmark, which should purely be about IO: https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=plaintext https://www.techempower.com/benchmarks/#section=data-r18&hw=... Phoenix, which is in Elixir, does 2.7% of the requests of the Rust frameworks. Chicago Boss, in Erlang, does 0.2%. Is this a realistic benchmark? I don't know; I can't say if the code for either of these implementation is good or not. But if it's a silly error, I think it would be good for Elixir/Erlang advocates to fix this. Early Rust implementations had extremely poor showings too. I tend to think of Erlang as being extremely reliable, with acceptable performance, rather than being the fastest IO language in the West.

di4na 7y ago
As an admin of the elixir slack, i have to handle that one a lot. It is not really realistic at all no. But mostly because the benchmark is not realistic of a production load. That said we should do better. The main reason it is not fixed is that the few members of the community that tried to fix it had a really bad experience interacting with the repo and getting feedback of impact and simply lost interest. And we have not have people motivated enough so far because they do not really care about the benchmark. Ofc it matters to people that are not in the community but well... That said, yes we would never be close to Rust anyway (probably) but we could probably have a far better standard deviation than Rust. Something that tend to matter in production a lot but people forget reading benchmark is the spread of the response time vs the average one. We should also perform better in a noisy environment like the "cloud" one. There are hopes that the recent EEF marketing group could help find volunteers or finance someone to fix it.
- steveklabnik 7y ago
  Yep, that makes perfect sense. I've had good experiences contributing, but it can be tough... It's also 100% true that benchmarks are not representative of production loads. Sadly, it's also 100% true that programmers make decisions based on benchmarks that aren't representative of production loads. It's a real catch-22 situation.

adwn 7y ago

> Being nitpicky, but I'd argue Erlang only falls down on speed where it's computationally bound. Where it's IO bound (e.g. a prototypical chat server) Erlang has excellent speed characteristics - where speed is measured in concurrency and latency. At the scale where asynchronous IO becomes interesting, speed is computationally bound. Think maintaining tens of thousands of TCP connections. You can either spawn a single OS thread for each connection, which gets prohibitively expensive with regards to memory consumption, or you can use asynchronous IO and have a couple of native worker threads, approx. 1 per CPU core. If Erlang can handle, say, tens of thousands of TCP connections with one Erlang thread/actor per connection, then only because it is using an implementation of asynchronous IO in the background.

spinningslate 7y ago
> If Erlang can handle, say, tens of thousands of TCP connections with one Erlang thread/actor per connection, then only because it is using an implementation of asynchronous IO in the background. Yes, it can. That's one of the BEAM's key strengths (the Erlang VM). It presents a simple, uniform concurrency abstraction - the process - to developers. Note these are application-level processes, not OS level. They're very lightweight and it's possible to spin up tens of thousands on a single machine. The VM multiplexes user processes over the underlying hardware (threads/cores). More here [0]. [0] https://stackoverflow.com/questions/2708033/technically-why-are-processes-in-erlang-more-efficient-than-os-threads https://stackoverflow.com/questions/2708033/technically-why-...
- Manishearth 7y ago
  We used to have M:N threading in Rust's runtime -- this is one other way to achieve what we wanted. It imposed a cost on all programs, including those which weren't using it, and iirc it didn't fit well and wasn't flexible enough (I'm not sure of this) and it got removed. Async/await/futures with library level scheduling is basically the only way to get the benefits of application threads in rust without such downsides.
  - dboreham 7y ago