As a developer with experience in many languages, Elixir feels very attractive to me because of its (and in general the OTP platform’s) uniqueness. However, so far it feels like I’m missing something. Every thread about this talks about mass concurrency, but that just isn’t that useful? Like I genuinely haven’t found a use for it outside of (very) big data analysis and networking. I feel like I’m missing something though? Like I look at the documentation for OTP and for Elixir, and it feels like it has huge potential but I can’t seem to find a use for it. Any thoughts?
2 Likes
@ferd wrote a wonderful take on it a few years back, it talks mostly about Erlang, but all of it is applicable to Elixir. 
15 Likes
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.
16 Likes
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…
10 Likes
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.
19 Likes
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
13 Likes
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.
8 Likes
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.
6 Likes
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”?
6 Likes
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).
9 Likes
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.
1 Like
One thing that hasn’t been mentioned yet so far is that Erlang (and Elixir) are pretty good at hiding system details. It’s a virtual machine (or OS) on top of which your applications are running. And most code would just run fine on any operating system (disclaimer: haven’t tried Erlang on Window since a very long time). In some other languages, you have to choose between one of n competing thread or async implementations, zillion different ways to do locking - possibly unsafe, and one library might use this implementation, the other that and both do not work well together. Erlang just got this right from the beginning - it provides powerful concurrency building blocks like almost no other language.
3 Likes
Ther internet is a medium of communication. OTP supports communication and coordination across complex systems with minimal downtime (communication breakages).
OTP can also be used for complex software system where different components communicate with each other, even though the system itself is on a single device.
Something that I often don’t see listed is the powerful live debugability, which is especially useful under duress in production. Another amazing book by @ferd is Erlang in Angler, which touches on this. Compared to debugging production issues in Java using things like JVisualVM and remote IDE support, I think the ability of attaching a remote node and dropping straight into the shell to look at ETS tables, change process state, call processes, and made code changes is super powerful.
5 Likes
Indeed, having the possibility to just spin up a remote console to your production instance is magic even to this day.
In the world where software inevitably breaks, having the option of debugging the production environment without downtime or needing to do redeploys is invaluable sometimes.
2 Likes
This.
Observability is a huge part of what makes the BEAM great to use in production. I dread maintaining anything else in production.
1 Like
I missed this—this is a great comment and exactly how I feel about Elixir. I always say it’s a great mix of elegant and scrappy. And I don’t use “scrappy” in a negative sense at all—it’s just another way to say “pragmatic” though instead of picturing a stuffy academic, I picture someone getting stuff done. I believe it was @D4no0 who called with a “ghetto monad” 
We don’t have a codified bind, but we get on with with just fine, and it’s much easier for everyone to grok. Want partial application? Here ya go: mod_2 = &rem(&1, 2). You mad cos it’s not automatic? Sure, could be cool, but I’m certainly not yearning for it 
(the “object first” convention makes it a non-starter anyway).
4 Likes
Some excellent points already in this thread, and since it’s open on my device (I haven’t been able to resist it!) I hope @sasajuric won’t mind be showing you some of what he says in his book - I read it last night and immediately thought of this thread!
So technically, there are few languages and runtimes that come close to Erlang and Elixir, but there’s more to Elixir than just technical merit. It’s something I hope to cover in a blog post one day but one of my favourite things is how it, and projects like Phoenix, show you a better way.
Often when programming in another language I used to think to myself, surely there is a better way!? And that’s exactly one of the things I felt Elixir, with people like José and Chris, were promising - because they came from the same languages and saw the same pain points and issues we did.
This is why you hear things like Phoenix is not your app, and why Elixir and Phoenix are a little bit more explicit - there’s less ‘magic’, and the magic there is is arguably better balanced. I also like how we’ve got a few different ways to build apps, so you could have a Phoenix monolith (so a bit like Rails), and at the other end you could have an app made with Umbrellas (or Prag Dave’s microservices inspired architecture as per his Elixir for Programmers course) and then, in the middle, you’ve got Phoenix Contexts, which is an example of what I mean by Elixir (in this case Phoenix) showing you a ‘better (sane) way’.
And there’s loads more! (But you’ll have to wait for my blog post if you’re interested in my thoughts on this! 
)
In the meantime, why not join our Elixir In Action Book Club? Saša Jurić, the author of the book is taking part as well as the mighty @bjorng - who is not only one of the core team members of Erlang but also one of the 'B’s in BEAM 
6 Likes
There’s a lot of potential for concurrency even in simpler systems. I gave two talks in the past where I tried to demonstrate this:
7 Likes
Yeah, it’s also everywhere unless you’re working on a highly synchronous possibly embedded problem:
3 Likes
