Here’s my anecdote.

I built 3 production projects in elixir around 2015-2018, and it was a blast to learn and work with. Those were interesting projects that were a great fit for the stack. One was March Madness bracket game which required a huge throughput on day one, and another was a football game audience play calling each play from their phone as the team is playing live at the stadium. This one needed a lot of timing coordination and poor connection handling. I even put out an open source fast/customizable leaderboard on top of ETS.

However, I didn’t feel the need for this stack on most projects, and if I’m totally honest, I never got good at the novel way of building applications in it.

While it was very enjoyable, everything felt a little awkward. Even 3 years in I constantly felt that I’m not doing it right, and I’m fighting the language to do data transformations in a purely functional style. I never got used to writing Ecto queries, and always had to look up their syntax. Plus, there didn’t seem to be a good architecture story, just isolated praise of OTP. And Phoenix further fueled the confusion, making it hard to understand whether I’m supposed to reason about my app like a Rails app (just build controllers, models, and views) with no regard for processes, or I should orchestrate some creative supervision trees, that I can’t even tell how they would be arranged in a typical web app. Going back to Ruby on Rails was kind of back to super productive comfort zone after a bit, and I just continued staying there.

I’m still looking back at Elixir with nostalgia, wondering if I’m going to have a chance to go back to it and really make it an extension of my arms/brain like Ruby had become. And whether I can do all that amazing supervision-based architecting I keep theorizing in my mind. I loved Dave Thomas’s vision (and agreed with his controversial takes) and really wished I could get as good as Sasa Juric at really deeply reasoning in this framework. Maybe one day.

Used elixir a few years ago for tutorials and such, worked fine.

Tried to use it again in 2023, vscode extension would break. Tried on 2 windows machine and one linux machine, exetension always broke.

I then figured out why (I don't remember the exact reason, it was one of those "yeah I can see why it didn't work and it's my fault but it kinda isn't really" situations) but at that point I was done because I had better stuff to do.

Point being, if you want your stuff to be adopted make sure the tooling is noob friendly. The noobs of today can be the professionals of tomorrow.

Especially today when there is so much stuff to learn and elixir is so far from the usual and requires a certain time investment

The simple reason is that Elixir is competing in the backend web-services space, which is a very crowded space with many equally-compelling alternatives.

As someone who likes working with off-meta languages, it's clear that the default state for any new language is to die an early death. The fact that Elixir hasn't died is testament to its strengths.

Got me. Running Akkoma on Elixir is a piece of cake, relatively speaking. Trying to run Mastodon on Ruby by simply using the latest version of the required Ruby components hasn't worked for me, ever.

The idea that we'd need to keep a snapshot of modules from a specific date in order to run certain software is ridiculous, and the idea of running it in a container like Docker is just giving in to bad practices. Too often it means things are too fragile to update when there are security issues.

I haven't seen this happen with Elixir. What do they do better / differently from Ruby that updating doesn't cause the house of cards to come crashing down?

Since this thread is going to be bait to more experienced Elixir devs, can someone tell me books, blogs, etc that you like that discuss performance in Elixir?

I am working on an Elixir project that in no circumstance should be taxing but it's falling over miserably at like 100 - 200 events per minute. The detail is it is distributed-ish IoT. I didn't write it, the person(s) who did write it are gone, and no one else writes Elixir. I've gotten some good gains already but I'd like to squeeze the 80 - 90% of juice I think I can get before resorting to beefier hardware.

I've gotten into instrumenting and measuring it and I have some ideas but I'd love to hear others point me to other ideas. The real problem is that the hardware is miserably underpowered and it is real-time, by that I mean I can't defer, schedule for later, or de-prioritize anything.

---

To actually contribute, I really like Elixir. I am not yet sure why I would advocate for it over something more 'simple' like nodejs (My background is, accidentally, Javascript World) but it's certainly a very nice language to write in. It feels magical but not too magical where you get scared it's trapping you into its web.

Before anyone jumps too much on me for it, I gauge "simplicity" by how many people can I hire to write it. You can barely swing a cat without hitting 3 competent Javascript developers. I tried for many years to hire another golang dev so I could write it professionally, I only encountered a few despite having been in most interviews my employers would do. With that said, it may just be that the Venn diagram between "writes Javascript" and "writes golang" is small.

Ultimately, Elixir is a functional programming language.

Has any functional language ever really become popular?

No manager is going to lose their job by hiring 10 Python and JavaScript engineers to accomplish what could be done with 1 Elixir engineer. And that’s how most time and effort is allocated in our tech labor market economy. It’s by working backwards from “I want to still have a job in tech next year.”

The number of people who are calculating which language to write in by thinking “how can I write a fault-tolerant distributed system with less time and energy so that I can quickly release performant products” is minuscule. The lack of popularity of Elixir is evidence of this I think.

In regards to your point on ZIRP: billions of dollars have been poured in to LLMs that are biased toward legacy languages like Python and JavaScript. Even the file structure of these languages is conducive to LLMs. A HTTP server can be and is frequently defined in a single file or function, where everything from socket creation to connection handling to request parsing to database queries to response can be composed in literally a few lines of code. This immense expressiveness is a testament to the power of HTTP. But as I’m sure we’re all aware there are limits to what can be accomplished with a single machine serving these stateless requests, and the limit can be reached very quickly. But LLMs gravitate towards producing these haiku-like incantations, it’s trivial for them.

Elixir’s power comes from having a well-defined API and explicit failure modes for each of these layers, each in their own expressive modules. This makes it difficult for LLMs to write Phoenix code when they’ve been optimized to output a 3-line FastAPI decorator-definition-query endpoint. Each of these layers in Phoenix is by itself quite simple, each layer has about 2-4 required functions to be implemented, and Phoenix can generate all of these for you. But ChatGPT doesn’t seem to be able to grok it all at once the way a good engineer can after readings the docs for an afternoon.

Will Elixir survive an era of programming where RTFM is a lost art? I suppose we will find out soon enough!

In a commercial setting (i.e. not a side-project) the choice of programming language is also a business decision.

The main factors being:

- How large is the pool of available candidates for this language? A recruiting risk.

- How mature is this language? A business continuity risk.

A limited job market, considerably smaller ecosystem (compared to java/python), and lack of support from major tech corporations (unlike Go or Rust) makes it challenging to adopt Elixir.

At my company , we inherited a legacy Elixir service, but we're actively moving away from it. We found it more practical to rewrite the service in Go (entire team is proficient in + LLMs make it easier to migrate) rather than invest time and resources into learning Elixir and its associated ecosystem. The return on investment for mastering Elixir didn't justify the effort required, given our specific circumstances and needs.

I do like to tinker with Elixir for hobby projects. But supporting a whole new language in a company is an uphill battle, that's incredibly hard to justify.

From what i've read, it is the "upgrade" to rails for people who want higher scale. I don't know if I agree, as Rails definitely does scale if you know what you're doing. Would love to hear more about others experience using Elixir for fast, low-latency high throughput scale.

I can't say about mass popularity but for me personally the lack of static types has held me back from using it. Now that it's being gradually introduced I am looking forward to trying it

It's a wonderful language. Unfortunately the only places I've been able to use it and get paid were places where I ultimately had the decision making ability of the tech stack.

Why isn't it used? It's niche and betting on such a small community is risky for the majority of companies. Why use Elixir when you could hire 10 engineers to pump out javascript. That's the mentality of most.

Hiring for elixir was great, it self selected people who wrote code as their craft. You kind of have to be curious about code to even be aware of Elixir, know how to write elixir. These types of devs would pick it up really quickly because the language is just so damn ergonomic.

I'm using Elixir now, and I wake up so happy that I get paid to do this. I am really blessed.

I'm Not a Professional dev, but a sysadmin WHO Likes to code. I learned a bunch of languages over the year. C#, Java, Python, JS/TS, PowerShell, Rust. Not professionally, but enough to finish some Personal projects.

Elixir was so vastly different, had such a small community that I lost interest very, very fast. It just felt like a waste of time. Any of the other languages I learned I could and did apply at my job. Even just knowing the languages helps a great deal when evaluating the next tech stack to implement. And Elixir just doesn't. It's a niche language for niche applications and doesn't personally help me in the least.

I also just did not like the DX. I did fail to understand how to use the VS Code debugger to step through functions. Printing to console to inspect variables felt like being in the stone age again, no thank you.

I still believe Phoenix LiveView is a really, really good tech and currently wish that Svelte could implement something like that.

And that's my personal reason for not looking into it.

Straight up - you should not use it without much more compelling reasons than those you have outlined.

It's not OK as CTO to push your company to use for favorite pet slightly obscure technology.

The company needs ordinary technologies to get its job done - Java, C#, TypeScript, Golang, Python, something like that. Maybe even Ruby but frankly that causes hiring headaches too.

Unless the company is doing something so extraordinary that it NEEDS Elixir over the technologies above, and it probably doesn't need it.

I know companies that went all in on Elixir - they spend all their time trying to recruit Elixir developers from a tiny recruiting pool, or trying to find people willing to learn it and bring them up to speed. This is poor business practice - there was nothing they were doing that could not be done just as effectively with any of the other major languages.

Just use normal technologies, have all the people and documentation and training and other resources available and get on with the job of building the software that the business needs.

I guarantee you that the company that went with Elixir due to the enthusiasm of some current or past CTO will have to go through the painful process of getting rid of it.

Elixir is for personal projects. Corporate software development is mature enough now that ordinary technologies are extraordinarily powerful and there's almost no reason sufficiently compelling to not use them. Toys are for home, tools are for work.

I regret using it. Recruiting risk. Smaller ecosystem. I should have gone for Python.

Because it is not strictly typed language.