Folks, if you have problems doing async work, and most of your intense logic/algorithms is a network hop away (LLMs, etc.), do yourself a favor and write a spike in Elixir. Just give it a shot.
The whole environment is built for async from the ground up. Thousands and thousands of hours put into creating a runtime and language specifically to make async programming feasible. The runtime handles async IO for you with preemptive scheduling. Ability to look at any runtime state on a production instance. Lovely community. More libraries than you might expect. Excellent language in Elixir.
Give it a shot.
I did an interview for the job I'm currently at, and we were discussing in it an architecture for live updating chats and I said I wouldn't reinvent the wheel and just use the approach Phoenix LiveView uses, which is to have a basic framework loaded client-side that would just apply diffs that comes from a websocket to the UI and have the chat update using those diffs. Turns out this is exactly the architecture they use in production.
People are reimplementing things that are first class citizens in elixir. Live content update, job runners, queues... Everything is built into the language. Sure you can do it all in typescript, but by then you'll be importing lots of libraries, reimplementing stuff with less reliability and offloading things like queues to third party solutions like pulsar or kafka.
People really should try elixir. I think the initial investment to train your workforce pays itself really quick when you don't have to debug your own schedulers and integrations with third party solutions. Plus it makes it really easy to scale after you have a working solution in elixir.
I agree in principle but I think that your average Python developer that thinks that Node.js is an improvement over Python is going to have seizures if they need to switch to Elixer. It's a completely different way of working.
I don't know... I'm your average python dev. I don't think nodejs is necessarily an improvement, but when I got to pick up a bit of elixir, and after struggling a bit with the many collection types and the pattern matching, when it clicked it was really eye-opening. So I don't think this is out of the league of the regular dev. I think if we were talking about Haskell that would probably apply, but elixir is fine. Even metaprogramming is very intuitive in elixir once you get the hang of it. It's just a very well designed language.
Indeed it is, and congratulations to making it to the other side of the ascent.
It's interesting, for some people Elixir really clicks, others can't make heads or tails of it. I don't mind Erlang either, but I understand that that is really an acquired taste.
Still, there is a long way for me to actually be productive with elixir. Sure I can now solve some advent of code challenges with it, but I still haven't done a proper project with Liveview and OTP. I've seen enough though to have me convinced this is the way.
I have always been interested in Elixir but have been putting off learning it because I don't see many job opportunities for it(at least here in Asia).
But your comment has convinced me to try it since I am having a bit of NextJS burnout.
you wouldn't need kafka or pulsar if you use elixir, why ?
I said you'd need those if you were coding jobs in typescript natively, without aid of cloud primitives like AWS SQS and Lambda, not with elixir.
sorry, maybe I wasn't clear enough when asking.
what about elixir that eliminates the need for kafka. simple queues I understand but kafka ?
Sure Kafka is used for much more advanced applications. In autonomous microsservices if I'm not mistaken these topics could be even used as the source of truth so that each specialized database could be reconstructed by replay. I'm saying that for simple topics that are just used to coordinate job queues, elixir can handle it just fine.
Persistent job queues?
Using a lot of Typescript and Python in my current role and I find myself missing that part of Elixir. Ecosystems are night and day though. For what we're doing we'd have to write far too many libraries ourselves in Elixir and don't have the time right now.
I don’t find the developer experience to be good, its not just the lack of types altogether but also the delays imposed by having compilation steps to run tests.
A lot of the affordances in the ecosystem have been supplanted by more modern solutions for many use cases, like Kubernetes.
Elixir also opens a number of footguns like abuse of macros; these are some of the reasons to second guess switching.
I think that one of the strongest reasons for switching would be that if you are willing to trade off all of this in exchange for the ability to do zero downtime deploys, not just graceful shutdowns and rollovers. Like if you’re building a realtime system with long lived interactions, like air traffic control system or live conferencing systems.
It can sometimes feel like an esoteric or regrettable choice for a rest api or rpc/event driven system. Even if you want a functional language there may be better choices like kotlin.
> its not just the lack of types altogether
??
Elixir is strongly but dynamically typed.
On the progress of static typing:
https://arxiv.org/abs/2306.06391
This is an absolutely horrible idea. I’m not questioning the technology choice. But as someone interested in their career, it makes no sense to focus on a language or technology that is not popular. It’s both bad from the recruiting side trying to get developers who are smart enough to care about their n+1 job and the developer side.
There are probably less code samples and let’s be honest this is 2025, how well do LLMs generate code for obscure languages where the training data is more sparse?
Maybe for you! That's your call. I'm also interested in my career.
I've had 3 Elixir jobs and 2 Rust jobs in the last 10 years. All were on real products, not vaporware. I learned a ton, worked with great people, and made real friends doing it.
Luck? Skill? Who knows. It's not impossible to work with the technology of your choice on problems you find interesting if you're a little intentional.
Nothing ever gets better if everybody just does what's already popular.
I’ve made a very lucrative career moving from .NET to BEAM. I don’t even work with it currently but the fact I’ve shipped it for some pretty niche systems shows versatility and consistently goes in my favour when getting hired.
I work at a company doing full-stack Elixir with most of our devs all heavily using AI as they please to augment their workflow, and our CTO was genuinely concerned that our main competitor, a Python shop, had a leg-up on us for this exact reason.
He spent time running benchmarks for 0-1 apps and all kinds of other metrics and found basically no appreciable difference in the speed or accuracy of AI at generating Elixir vs. Python. Maybe some difference, but honestly it just doesn't exist enough to matter.
About LLMs: I did last year's advent or code with Elixir and when I forgot to turn off copilot it had no trouble writing whole implementations of functions, even if I had a very idiosyncratic style.
Most code is boilerplate and that's where LLMs shine, I don't think this specific issue is very important.
> this is 2025, how well do LLMs generate code for obscure languages where the training data is more sparse?
You'd be surprised: https://github.com/Tencent-Hunyuan/AutoCodeBenchmark/blob/b1...
Wow.. Elxir is the highest? That's interesting
> But as someone interested in their career, it makes no sense to focus on a language or technology that is not popular
A: why in gods name B: Every language, every framework and every tech stack is 1 month to 5 years away from being legacy crap. Unless you're learning something like KOBOL it's better to be able to use a variety of languages and show that you can adapt.
Java has been around and popular in the enterprise since 2002 and .Net not too far behind. JavaScript will survive the heat death of the universe.
Reminds me of the time I was on a team doing stuff in Erlang for no reason
>how well do LLMs generate code for obscure languages where the training data is more sparse
LOL. Speaking about absolutely horrible ideas ...
You might not like LLM code generation or corporations encouraging it. Just like I might not like gravity. But I am not going to jump out of a 25 story building. I accept reality for what it is.
Many people code out of curiosity and/or to learn new things and dgaf about whether recruiters will have trouble finding them, mega-lmao.
As an acceptor of reality, you can begin to accept that as well.
I have a strange feeling that most people haven’t found a method to get over there addictions to food and shelter. If they want to exchange labor for money to support those addictions, they have to care about what recruiters want whether external recruiters or internal recruiters.
A lovely language with an incredible web framework (Phoenix, LiveView). However, not easy to pick up for people with only imperative programming experience.
I had to switch my project to .NET in the end because it was too hard to find/form a strong Elixir team. Still love Elixir. Indestructible, simple, and everything is easy once you wrap your head around the functional programming.
It. Just. Works.
As someone who has spent my whole career in somewhat niche things (ROS, OpenWRT, microcontrollers, Nix), I think the answer for how to hire for these is not to look for someone who already has that specific experience but rather look for someone curious, the kind of person who reads wikipedia for fun, an engineer who has good overall taste and is excited to connect the dots between other things they've learned about and experimented with.
Obviously that's not going to give you the benefit of a person who has specifically worked in the ecosystem and knows where the missing stairs are, which does definitely have its own kind of value. But overall, I think a big benefit of working in something like Elixir, Clojure, Rust, etc is that it attracts the kind of senior level people who will jump at the opportunity to work with something different.
And what happens when I’m looking for that next job? I haven’t interviewed for a pure developer job since 2018. But the last time I did, I could throw my resume up on the air and find a job as someone experienced with C# and knew all of the footguns and best practices and the ecosystem. I’m sure the same is true for Java, Typescript, Python, etc.
This is excellent advice.
Thanks.
One nice side effect of having done this is having a small rolodex of other people who are like that.
So, like, if I had a good use case for Elixir and wanted a pal to hack on that thing with, I know a handful of people who I'd call, none of whom have ever used Elixir before but I know would be excited to learn.
Yes, same here. And that has come in very handy more than once. But my merry band of friends isn't getting any younger, I think the youngest in our group is now mid 30s or so, the bulk between 50 and 60.
As someone who who's a polygot programmer, I've always agreed with this in theory; however, the biggest challenge I've found in giving Elixir a shot is that, well the job market doesn't seem to favor ANY elixir jobs out there...especially for someone who's only made 'toy' apps in Phoenix. And for prototyping apps, I'm just faster in Ruby/Rails to make it worth it PLUS if you want to debug ML/LLM scripts you have to know Python anyways.
Any recommendations for someone looking to break into the Elixir space in a serious (job-related/production app) way?
There are quite a few Elixir shops that are willing to hire people who don't have a ton of experience with Elixir but have experience building and understanding systems generally.
So my advice is, try to bolster your story that you can design and build systems (regardless of language), learn what is needed to get the job done, and _communicate_ your knowledge of those systems to people. Good teams will recognize this regardless of prior specific tech.
Source: I've been on hiring panels at multiple companies that used Elixir extensively and the factors that led to us making offers to candidates were rarely their preexisting Elixir experience.
Can someone explain a plebian C/python/java/go programmer with good idea about languages & runtimes:
==> what makes erlang runtimes so special which you don't get by common solutions for retries etc?
Normal Erlang code has a fixed number of reductions (function calls) before it must yield to a scheduler. Processes also have their own stacks and heaps and run garbage collection independently. The result is that no single process can stop the whole system by monopolizing CPU or managing shared memory.
The Erlang runtime can start a scheduler for every core on a machine and, since processes are independent, concurrency can be achieved by spawning additional processes. Processes communicate by passing messages which are copied from the sender into the mailbox of the receiver.
As an application programmer all of your code will run within a process and passively benefit from these properties. The tradeoff is that concurrency is on by default and single threaded performance can suffer. There are escape hatches to run native code, but it is more painful than writing concurrent code in a single-threaded by default language. The fundamental assumption of Erlang is that it is much more likely that you will need concurrency and fault tolerance than maximum single thread performance.
Yes but NodeJS is also built for async. I get why Discord or FB Messenger use Elixir or Erlang, but they're huge scale.
Elixir is dead simple to use and the LLMs do a good job with the Phoenix boilerplate now. Hex.pm and Mix for building and dependency management are miles better than anything node has to offer as well. The developer experience is just really good.
Yeah moving from python to node for concurrency is insane.
Moving from Python to Node for per-process fully-fleshed out async and share-nothing concurrency however is perfectly sane.
Using any of them for backend is insane, but what do I know, I have to suck it up and use Next.js for some SaaS extension SDKs, while I would rather be using JVM, CLR, or even Go with its spartan design.
JS haters could stand to understand the language has strengths even if it has well known warts.
That's the main reason to move. Same reason people moved from Java to Kotlin, except that might change now with vthreads.