6 ms·

Is Elixir/Erlang considered superior to Go for writing high concurrency web servers?

jadbox 8y ago
As far as from my tests and what I've seen reported online, Go and Rust have a substantial lead (20% ish) over Erlang for high throughput servers. EDIT: I believe this is partially due to Go being a lot more CPU efficient overall than Erlang (see below). So for simple servers, Go and Erlang will match performance, but for slightly more complex web servers that need to crunch some data, Go [and Rust] will outperform the Erlang VM. https://stressgrid.com/blog/benchmarking_go_vs_node_vs_elixir/ https://stressgrid.com/blog/benchmarking_go_vs_node_vs_elixi...
- fermuch 8y ago
  I would add the detail that for both erlang and elixir, running in one core, multiple cores, or multiple machines is seamless. Clustering is easy.
- StreamBright 8y ago
  Well one of the fastest HTTP library out there is rapidoid and fasthttp comes very close to it as well as actix-raw, hyper and tokio-minihttp. Erlang and Elixir is lagged behind with a non trivial margin.
rakoo 8y ago
Not na expert in any of the languages by any means, but Go and Erlanger/Elixir focus on different things: - Go wants to be performant at high concurrency scale - Erlang/Elixir wants to keep running at high concurrency scales, whatever the issues are in your application code. Performance comes second. There's no clear cut answer to your question; I guess if you trust yourself to write servers that will hold a large number of connections while doing a lot of processing then Go has an advantage, otherwise you should probably trust the man-centuries behind the BEAM VM and follow the various blog posts/presentations explaining how you can fine-tune your machine to get to super large scales.
- keithnoizu 8y ago
  I suspect it's probably much more straight forward to horizontally scale across nodes with Erlang/Elixir and OTP than with Go.
- anthony_doan 8y ago
  > Performance comes second. I want to state that performance is too generalize here. BEAM VM also have a goal of low latency which can be consider as performance. I'm not entirely sure if GO is aiming for that or not. I would never do any numerical stuff on BEAM though, it's very slow. This article is a bit dated but is interesting between Go and Erlang: https://www.theerlangelist.com/article/reducing_maximum_latency https://www.theerlangelist.com/article/reducing_maximum_late...
  - rakoo 8y ago
    Very true, thanks for the article. Go also wants to minimize GC duration by making it per-goroutine and some fancy algorithms to make it as short as possible, so I'd say it's part of it's goals too.
brightball 8y ago
Depends on the definition of superior. If it's pure benchmarks, then Go is usually going to come in a little bit ahead. When you get into comparing language design, underlying architectural decisions, problems solved/created/avoided by those decisions it gets more complex. I did a big write up for code ship a couple of years ago. Had a solid discussion on HN and the comparison remains fairly accurate. https://news.ycombinator.com/item?id=13497505 https://news.ycombinator.com/item?id=13497505
nathan_long 8y ago
I don't know Go, but that probably depends on your goals. To quote myself from elsewhere: > Efficiency in the BEAM is mainly in service of its primary goal of fault-tolerance. If one process crashes unexpectedly, the others should continue. By the same logic, if one process is CPU-intensive or IO-blocked, the others should keep making progress smoothly. And if processes are good for isolating errors and performance issues, they should be cheap enough that we can run a lot of them at once. Those assumptions are baked into how the BEAM manages processes. If raw speed is your only goal, the BEAM probably isn't the best choice. If consistent speed and stability matter, it may be. More on this at https://dockyard.com/blog/2018/07/18/all-for-reliability-reflections-on-the-erlang-thesis https://dockyard.com/blog/2018/07/18/all-for-reliability-ref...
- mastry 8y ago
  That was a helpful and interesting article. Thanks.
alexgaribay 8y ago
In terms of raw performance, Go will be faster. However, the differentiator here is that the BEAM gives you the guarantees and tools to write highly concurrent applications with a sane mental model, fault-tolerance, and isolated processes. As a sibling said, it's fairly easy cluster applications. Additionally, if something truly needs to be ran in another language for performance, you can write a NIF in Rust or something and execute it from Elixir.
- StreamBright 8y ago
  Highly depends on which libraries are you talking about. Essentially you cannot claim that Go will be faster. You can say that fasthttp is faster than Cowboy for a hello world application. Every real world application is much more complex and the stack's performance will be decided by its slowest element.
  - Thaxll 8y ago
    Go is faster than Erlang and not by a small margin, Erlang is a dynamic and immutable language, it hurts performance compare to languages like Go. Some benchmark about pure CPU computation: https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/erlang.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Erlang is really slower than Java Go and Java now: https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... You see the big difference, Go and Java are on part but Go usually takes way less memory than Java. You can't have everything, message passing / immutability with no performance hit.
    - shaklee3 8y ago
      Instead of downvoting this comment, can someone write why this is incorrect? I realize it might not be a popular writing style, but references were provided.
      - RobertKerans 8y ago
ilovecaching 8y ago
What does high concurrency mean? Both of them give you less flexibility than is necessary to achieve highly efficient use of all threads on a multiprocessor system. For that, you'll need something like a pool of event loops using async/await. This is the system most common in high performance networking in C++, C, and Rust. Erlang and Go both sacrifice efficiency to improve maintainability and safety by offering a model that allows you to approach concurrency from a more synchronous mindset. Erlang in particular goes beyond Go in that the Actor model is considerably easier to avoid deadlocks and other concurrency bugs in at the expense of a much more opinionated system. Erlang is also less focused on reducing average latency as much as keeping latency predictable at scale. Long story short, Erlang, Go, and the rest are not apples to apples comparisons, and it takes investment in each language to understand the tradeoffs and use cases for each. You should also view them holistically, as in, what language can my team support, and will the wins from Erlang's message queues outweigh the smaller community, or will Go's mid tier performance be enough to avoid writing on top of the low level libevent and building a custom thread pool or fine tuning Go's scheduler.
- dscpls 8y ago
  Erlang tends to have excellent cpu utilisation if you follow the most basic principles in Erlang and OTP. The question is if you cannor want to write better concurrent code by rolling it yourself.

As far as from my tests and what I've seen reported online, Go and Rust have a substantial lead (20% ish) over Erlang for high throughput servers. EDIT: I believe this is partially due to Go being a lot more CPU efficient overall than Erlang (see below). So for simple servers, Go and Erlang will match performance, but for slightly more complex web servers that need to crunch some data, Go [and Rust] will outperform the Erlang VM. https://stressgrid.com/blog/benchmarking_go_vs_node_vs_elixir/ https://stressgrid.com/blog/benchmarking_go_vs_node_vs_elixi...

fermuch 8y ago
I would add the detail that for both erlang and elixir, running in one core, multiple cores, or multiple machines is seamless. Clustering is easy.
StreamBright 8y ago
Well one of the fastest HTTP library out there is rapidoid and fasthttp comes very close to it as well as actix-raw, hyper and tokio-minihttp. Erlang and Elixir is lagged behind with a non trivial margin.

rakoo 8y ago

Not na expert in any of the languages by any means, but Go and Erlanger/Elixir focus on different things: - Go wants to be performant at high concurrency scale - Erlang/Elixir wants to keep running at high concurrency scales, whatever the issues are in your application code. Performance comes second. There's no clear cut answer to your question; I guess if you trust yourself to write servers that will hold a large number of connections while doing a lot of processing then Go has an advantage, otherwise you should probably trust the man-centuries behind the BEAM VM and follow the various blog posts/presentations explaining how you can fine-tune your machine to get to super large scales.

keithnoizu 8y ago
I suspect it's probably much more straight forward to horizontally scale across nodes with Erlang/Elixir and OTP than with Go.
anthony_doan 8y ago
> Performance comes second. I want to state that performance is too generalize here. BEAM VM also have a goal of low latency which can be consider as performance. I'm not entirely sure if GO is aiming for that or not. I would never do any numerical stuff on BEAM though, it's very slow. This article is a bit dated but is interesting between Go and Erlang: https://www.theerlangelist.com/article/reducing_maximum_latency https://www.theerlangelist.com/article/reducing_maximum_late...
- rakoo 8y ago
  Very true, thanks for the article. Go also wants to minimize GC duration by making it per-goroutine and some fancy algorithms to make it as short as possible, so I'd say it's part of it's goals too.

brightball 8y ago

Depends on the definition of superior. If it's pure benchmarks, then Go is usually going to come in a little bit ahead. When you get into comparing language design, underlying architectural decisions, problems solved/created/avoided by those decisions it gets more complex. I did a big write up for code ship a couple of years ago. Had a solid discussion on HN and the comparison remains fairly accurate. https://news.ycombinator.com/item?id=13497505 https://news.ycombinator.com/item?id=13497505

nathan_long 8y ago

I don't know Go, but that probably depends on your goals. To quote myself from elsewhere: > Efficiency in the BEAM is mainly in service of its primary goal of fault-tolerance. If one process crashes unexpectedly, the others should continue. By the same logic, if one process is CPU-intensive or IO-blocked, the others should keep making progress smoothly. And if processes are good for isolating errors and performance issues, they should be cheap enough that we can run a lot of them at once. Those assumptions are baked into how the BEAM manages processes. If raw speed is your only goal, the BEAM probably isn't the best choice. If consistent speed and stability matter, it may be. More on this at https://dockyard.com/blog/2018/07/18/all-for-reliability-reflections-on-the-erlang-thesis https://dockyard.com/blog/2018/07/18/all-for-reliability-ref...

mastry 8y ago
That was a helpful and interesting article. Thanks.

alexgaribay 8y ago

In terms of raw performance, Go will be faster. However, the differentiator here is that the BEAM gives you the guarantees and tools to write highly concurrent applications with a sane mental model, fault-tolerance, and isolated processes. As a sibling said, it's fairly easy cluster applications. Additionally, if something truly needs to be ran in another language for performance, you can write a NIF in Rust or something and execute it from Elixir.

StreamBright 8y ago
Highly depends on which libraries are you talking about. Essentially you cannot claim that Go will be faster. You can say that fasthttp is faster than Cowboy for a hello world application. Every real world application is much more complex and the stack's performance will be decided by its slowest element.
- Thaxll 8y ago
  Go is faster than Erlang and not by a small margin, Erlang is a dynamic and immutable language, it hurts performance compare to languages like Go. Some benchmark about pure CPU computation: https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/erlang.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Erlang is really slower than Java Go and Java now: https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/go.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... You see the big difference, Go and Java are on part but Go usually takes way less memory than Java. You can't have everything, message passing / immutability with no performance hit.
  - shaklee3 8y ago
    Instead of downvoting this comment, can someone write why this is incorrect? I realize it might not be a popular writing style, but references were provided.
    - RobertKerans 8y ago

ilovecaching 8y ago

What does high concurrency mean? Both of them give you less flexibility than is necessary to achieve highly efficient use of all threads on a multiprocessor system. For that, you'll need something like a pool of event loops using async/await. This is the system most common in high performance networking in C++, C, and Rust. Erlang and Go both sacrifice efficiency to improve maintainability and safety by offering a model that allows you to approach concurrency from a more synchronous mindset. Erlang in particular goes beyond Go in that the Actor model is considerably easier to avoid deadlocks and other concurrency bugs in at the expense of a much more opinionated system. Erlang is also less focused on reducing average latency as much as keeping latency predictable at scale. Long story short, Erlang, Go, and the rest are not apples to apples comparisons, and it takes investment in each language to understand the tradeoffs and use cases for each. You should also view them holistically, as in, what language can my team support, and will the wins from Erlang's message queues outweigh the smaller community, or will Go's mid tier performance be enough to avoid writing on top of the low level libevent and building a custom thread pool or fine tuning Go's scheduler.

dscpls 8y ago
Erlang tends to have excellent cpu utilisation if you follow the most basic principles in Erlang and OTP. The question is if you cannor want to write better concurrent code by rolling it yourself.