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 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.
> 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.
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!
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.
I would learn Elixir instead (unless you want to specifically learn Erlang) as it is a sort of a more modern Erlang and you get access to all Erlang ecosystem for free. Years ago, I switched a codebase from Erlang to Elixir and it was a breath of fresh air. Note that I like Erlang a lot, but Elixir even more.
The `maybe_expr' meta pattern matching fallback mechanic is nice, and can surely help avoid a lot of boilerplate code while simultaneously encapsulating the logic in a structure which is easy to read and reason about. It's also not a thing in any other programming language I've learned- C, Java/Scala/C#/C++, Go, Javascript, Tcl, Bash(lol), PHP, Forth, ML, and so on.
I had to look up it's usage though, because I'm new to both Erlang/BEAM and Elixir.
You do realize that Rust, C#/F#, Kotlin/Scala, now Java to an extent, pretty much all FP and many other languages have extensive pattern matching support?
I really appreciate that this software has been under continuous development, maintenance and improvement for so long. Its nice to see such long term support, no better way to preserve engineering insights, than continuing to use them in production.
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.
I love that the Erlang guys seem to be so open to Elixir being a big part of their ecosystem even relying on ExDoc for their new documentation system (I think everyone can see it's a big improvement over the brutalist UI that was there before). A lot of software projects would be ego driven rather than pragmatic on something like this.
aloha2436|1 year ago
spinningslate|1 year ago
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.
sidkshatriya|1 year ago
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.
neillyons|1 year ago
sergiotapia|1 year ago
https://hexdocs.pm/nanoid/readme.html
unknown|1 year ago
[deleted]
ollysb|1 year ago
mikl|1 year ago
victorbjorklund|1 year ago
sabzetro|1 year ago
mindri0t|1 year ago
nickpeterson|1 year ago
lkuty|1 year ago
systems|1 year ago
worthless-trash|1 year ago
I did write this, which is a port of the erlang design principals for gleam:
https://github.com/wmealing/gleam-otp-design-principals/blob...
systems|1 year ago
metadat|1 year ago
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...
neonsunset|1 year ago
unknown|1 year ago
[deleted]
flembat|1 year ago
cpursley|1 year ago
biorach|1 year ago
ouch
sph|1 year ago
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.
andy_ppp|1 year ago
mikl|1 year ago
unknown|1 year ago
[deleted]