11–20 of 53 posts
Hyped about json becoming a first class citizen. As an Elixir engineer and daily Jason user it will be great to rely on stdlib functionality. Jason is great, regardless!
Reading about Erlang always feels like getting messages from an alternate dimension where we as an industry made much better choices in the 90s about how we write distributed software.
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.
Reading about Erlang always feels like getting messages from an alternate dimension where we as an industry made much better choices in the 90s about how we write distributed software.
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.
Really like the new Erlang 27 docs https://www.erlang.org/doc/readme.html
Reading about Erlang always feels like getting messages from an alternate dimension where we as an industry made much better choices in the 90s about how we write distributed software.
> where we as an industry made much better choices in the 90s about how we write distributed software. 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…
> 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.
I think I’m going to just break down and learn erlang. I’ve been interested in it for awhile but mostly work in f#. I recently started looking at gleam but I don’t think learning it with no knowledge of OTP is a good idea.
Reading about Erlang always feels like getting messages from an alternate dimension where we as an industry made much better choices in the 90s about how we write distributed software.
this. Erlang's concurrency support is one of those things you can't unsee. Going back to sequential-by-design languages (which is pretty much every other industrial quality language bar go[1]) just feels cumbersome: 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 t…
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!");