C/C++/C#/Python/...: "You want concurrency? Sure. We have OS processes, and threads, and this cool new async doohickey. Pick whatever you fancy! Oh, but by the way: you can't use very many processes cos they're _really_ heavyweight. You can have lots more threads, but not too many, and beware corrupting the shared state. Asyc though, you can have _loads_ of things going on at once. Just, y'know, don't mix the colours up".
With Erlang/Elixir it's just:
"You want concurrency? Sure, here's Erlang processes. You can have millions of them. Oh, you need to communicate between them? Yep, no probs, messages and mailboxes. What's that? Error handling? Yep, got that covered too - meet the Supervisors"
--
[1] Counting Elixir as "Erlang" in this context given it also sits on the BEAM VM.
Functional programming languages: Unlimited good abstractions of unknown cost
I don't feel like there's a great third option. Go is pretty good.
e.g.:
var delay = Task.Delay(3_000);
var tasks = Enumerable
.Repeat(async () => await delay, 1_000_000)
.Select(f => f());
Console.WriteLine("Waiting for 1M tasks...");
await Task.WhenAll(tasks);
Console.WriteLine("Finished!");
Erlang is a nice piece of software.
However, let us not dismiss the massive progress the world of distributed software has made since 1990s _not_ involving Erlang too.
Look at the scale at which we _reliably_ access video, audio, email, messaging, e-commerce/trading on distributed systems around the world ! At high reliability too ! Google, Facebook, Amazon, Netflix, Microsoft, NYSE/NASDAQ, ... -- Imagine the millions or even billions of computer systems working, cooperating in various private and public "clouds".
Apart from a few prominent systems here and there (e.g. erlang at WhatsApp), most of these systems _DONT_ use erlang. For various reasons Erlang has _not_ been chosen by thousands of software architects when they choose to build their next distributed system. Even though erlang lets us build a distributed system with lots of properties out-of-the box easily, let's talk about some failings of Erlang:
- Erlang is not statically typed language unlike Java, Rust, C/C++ etc. This means an erlang compiler cannot create code that will run as fast as the aforementioned languages. The compiler simply just does not have that much information available during compile time
- Not being statically typed also makes it a bit more difficult to refactor the codebase. Would you be able to refactor a 1 million line Rust code base more easily or a 100,000 line erlang code base (even if you have used Dialyzer). My money is on Rust.
- Not being statically typed also means that you cannot verify or mathematically prove properties about your system using various techniques as easily
TL;DR -- A small team can build a highly capable system on erlang quite easily in 2024. That small team would probbly take longer if they used Rust/C++/Java because those languages are more low level and take more time for development. But if you can throw some $$ on the project, in the long run a system built in Rust/C++/JVM can run more efficiently (and be maintained more easily) on a fewer machines using specialized code written in Rust/C++/Java etc. In other words it's not everyday you need to build a distributed system -- when you do, it makes sense to specialize and build it on a technology stack that may be a bit lower-level and statically typed.
This comment is already too long enough.
I like Erlang, it has some nice properties but when building distributed systems other technology stacks can also offer some other great advantages too.
> the codebase. Would you be able to refactor a 1 million line Rust code base
> more easily or a 100,000 line erlang code base (even if you have used
> Dialyzer). My money is on Rust.
I have found that refactoring erlang is NOT like refactoring code in other languages, non trivial refactoring in rust is a LOT more complicated however I do understand the fuzzy feelings you get when type-safe code compiles correctly.
Most erlang refactoring that I see needing to be done is simply reapplying a different pattern to the gen_server or distributing load differently. I believe if refactoring is a "complex problem", the development team had not designed with OTP behaviors in mind. My view may be because I have limited experience in refactoring my erlang due to being a solo developer and my mind is stuck in OTP land, please correct me if you've experienced it differently, I feel that you're perhaps painting the picture a little unfairly there.
If programmers need type-safeness for BEAM and I believe Gleam Language supplies the security blanket that other languages provide. From my limited experience it does NOT provide any additional "speed" (I expect there are not many compiler optimisations that end up down on the BEAM level) however it does give you that level of confidence that you're not going to be passing garbage data through your functions.
I haven't taken anything you have said as a personal (or even against erlang), thank you for the discussion points.
Having been stuck in the js world my whole career, it’s really cool to watch a community that’s rooted in collaboration instead of competition.
I did write this, which is a port of the erlang design principals for gleam:
https://github.com/wmealing/gleam-otp-design-principals/blob...
I had to look up it's usage though, because I'm new to both Erlang/BEAM and Elixir.
https://chiroptical.dev/posts/2024-03-04-erlang-maybe_expr.h...
You can use it to execute a series of functions returning `either`-ish tuples and build up a railway oriented program.
ouch
Looks a lot like Elixir's. The previous one was functional, but a little barebones. A little colour, hyperlinking and syntax highlighting goes a long way. Also, navigation seems to be improved. I always lost my way navigating across Erlang modules to find a specific function.
The entire Erlang/OTP ecosystem got a boost of mind share with the explosion in popularity of Elixir, and it's so nice to see it improve at breakneck pace [1], with some cross-pollination between Erlang itself and Elixir. The ideas of Armstrong, Virding and Williams are in many ways far ahead than a lot of mainstream languages, and they were long overdue a revival under the spotlight.
Keep up the good work!
1: yet, it's still the most rock-solid platform to build services upon, and you can quote me on that.
It’s really a win for both, and I love it.