The strengths of Elixir / OTP / the BEAM (other than concurrency)

@ferd wrote a wonderful take on it a few years back, it talks mostly about Erlang, but all of it is applicable to Elixir.

My personal Nr#1 strength of Elixir is that you will be able to write production grade software in less lines of code than any other language. This means you will spend less time to create and maintain it, spend less money as a company to push a feature out and create less bugs for your customers.

The functional nature and process isolation do help here a ton and protect your from a whole class of bugs, while at the same time enabling the “let it crash” way of error handling which again saves you code as it let’s you focus on implementing the “happy path” and deliver value to your customers first.

Compare this with other scalable options, such as Java, Golang, Rust – These are amazing languages but you will spend significant time digging through technicalities to make the borrow checker happy in Rust, or have the correct error handling in Golang or write class boilerplate in Java.

Just my 2 cents.

Many apps don’t really take direct advantage of that, but benefit greatly in the libraries they use, eg. Bandit, NimblePool (used by Req/Finch), Phoenix Channels, LiveView, Oban…

If you dig into the history of Erlang, a primary requirement was fault tolerance. Those phone network devices had to keep running even if one call has an error. Processes and their memory isolation (and supervisors (and hardware redundancy)) were used toward that goal. Concurrency was kind of a happy side effect (especially given CPUs of the 80’s and 90’s).

In my opinion processes should be thought of primarily as a way of controlling the “blast radius” of an unexpected error, and secondarily as a wonderful concurrency primitive that is easy to reason about.

Sort of. If I recall correctly, concurrency was a requirement from the start to keep response times fair and reduce the risk of a small part of the system locking everything else up – such as a single phone call accidentally going into an infinite loop somehow. That it enabled the parallel execution of concurrent processes later on is a very happy accident

I think this is just trying to appeal to all the folks who believe their startup will hit Google-scale in a year (or ever) that seem to be prevalent in our industry (Rather, that is why there may seem to be such a focus on it)

Elixir is quite useful beyond the concurrency. It’s a really just a nice language and really-well suited for the web (and now beyond!). It’s hard to beat = as a match operator! One of the coolest things about Erlang is that it didn’t come from academia—it was developed to solve a concrete business problem that looks a lot like how the web ended up looking. You could kind of call it a DSL for writing client/server applications It also doesn’t suffer from the “If you aren’t using the heavy-weight features then there is no point” thing.

hey @ omerss2311!

Every thread about this talks about mass concurrency, but that just isn’t that useful?

I think it’s one of the hottest topics in programming languages world, as well as the one with which same world struggles… (which might seem hilarious, because fairly long time passed since first general purpose, multi-core/CPU systems started to appear.)

Async, non-blocking, parallel or multiprocessing, threads, green threads - you will see it everywhere pretty much: in fairly small or medium sized web apps, backends, different sort of ETLs, server software, client-side JS…

Random example: Goroutines - used so often it’s probably easier to find software with them than without. Take a look at Helm.

Many languages did not addressed the subject originally, in early iterations of their design, or did, but used dated standards/approach, and results more often than not… Are causing lots of discussions and/or friction

Take a look at Rust surveys or community discussions, initiatives - super hard to get it right, async API is kind of rough and complex to consume.

OK, where i am going with that?

Enter… Erlang/OTP and new generation of programming languages built on top of both.

Naive but obligatory disclaimer : pretty much all the things i am writing are personal opinion/anecdote, and here comes another one: i never encountered language or framework in which topic would be so easy to jump at, and incorporate into your software, without so many foot guns. i can’t really express how amazing it feels to me (and how many people ignore it, not even taking a look, because “meh, no static typing”).

… there is plenty more obviously, however this time i wanted to chime in reg. this, particular subject.

Is that an actual question, or is it a claim disguised as a question?

While I agree with the others that there is more to Erlang/Elixir and OTP than just being transparently concurrent and parallel, I believe it has to be restated that this is extremely valuable in a civilization where one of the most popular languages – Python – is still having a council of elders bickering whether or not to remove the global interpreter lock… while tech like Erlang/Elixir, Golang, Rust, OCaml and others are delivering super-parallel software today. Which is honestly hilarious to watch, I’ve been to their discussion boards and it gave me several good laughs.

So in case you were actually asking a question, my response would be “is that not quite a lot of value proposition already”?

Elixir is a very pragmatic and simple functional language.
It is imo the only functional language for blue-collar-coders like me.
I tried them all and failed. (Erlang is also easy but I could not live with the syntax).

Note: functional languages are a good thing (for most problems).

Besides OTP/BEAM there are definite advantages to Elixir/Erlang:

• Powerful pattern matching
• Immutability
• A macro system
• Functional style

If you prefer macros can remain in the background, but, like OTP, they are used to implement features that make Elixir enjoyable to work with.