| > 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. |
> 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.