[iterateoften]

I have been a big advocate for Elixir for 5 years before switching off.

My takeaways: love José Valim and the team and the libs they produce. The team is always humble and helpful and produces high quality content in both code and documentation.

Why I stopped using Elixir: I was using Elixir obsessively as a performance chasing tool, but then it just didn’t fill the gap properly:

1. Python (or other massively used language) is preferred for large SaaS apps where performance doesn’t matter. As an engineering manager, I can go out and hire a huge team instantly for Python.

2. Rust is much faster and not super difficult. When I ran out of optimizations for Elixir I found myself dropping down to Rust. Then asked myself why even use Elixir?

With those two points, Elixir, like Haskell, changed my programming mindset immensely, but as a professional context, quite frankly you have to use what you can build a team with. Elixir has very few engineers to source from.

[voicedYoda]

Regarding #1, as someone with managerial experience, I'm really tired of hearing, "We can't find enough Elixir resources".

That's a cop out excuse. On the Discord, Slack, and Elixir forums, there are hundreds, if not thousands of devs looking for work.

Often it is lamented that nobody can find enough Elixir engineers, but they also seem to have a very hidden agenda here. Executives just want the job done, and Elixir can do it, but all too often the trope of not finding enough resources is lauded about as a reason to stick to LANGUAGE_MANAGE_HEARS_ABOUT_MOST (Python, JS, RoR, et al).

Everyone also only wants Super-senior-staff-principal engineers for Elixir roles, with 20 years experience, and can live code a project to perfection in 3 hours. Maybe realize that as the community grows and engineers adopt to the language, it's ok to bring in early-careerist resources, or others who just are getting started out. Give them a book, some assistance, and keep working with them, and it doesn't matter who knows it at first, in 6 months you'll have a rockstar team.

[pg_1234]

It also goes the other way.

If you're a savvy dev and a search like:

https://www.itjobswatch.co.uk/default.aspx?q=Elixir%2C+Rust%...

comes up with zero for Elixir, you don't sink time into it.

If nothing else, you know that the low job availability puts you in a very weak bargaining position.

[djaouen]

This is the kind of attitude that would have seen Java jobs proliferate lol

[pg_1234]

The harsh reality is that when it's your livelihood, and not just a hobby, you HAVE to make these calls, whether you like the answers or not.

[dynamite-ready]

I mean, Elixir is definitely not a replacement for Rust. I imagine it as being closer to Node, Python, or possibly Java. And even then, it's a wild comparison, because of the way Actor Model concurrency is weaved into BEAM languages, in a way that no other language does.

For perf optimisations, you have Ports or NIFs (irc), where Ports are just knowingly volatile processes, and NIFs are FFIs, which is an almost universal feature across all languages.

But I suppose your experience is based on use case. And I would agree that commercial BEAM language experience is generally thin on the ground, if you're role is to build an engineering team (though I can't imagine Rust expertise being that much more abundant either).

One thing I would add, is Erlang/Elixir's emphasis on multi machine concurrency is somewhat at odds with the serverless future we're moving towards. But ignoring that (especially with vendor lock in issues), I often wonder why Elixir hadn't put a larger dent in the popularity of Kubernetes. Because BEAM's approach to managing multiple services across machines seems both much more powerful, and dev friendly.

[josevalim]

> One thing I would add, is Erlang/Elixir's emphasis on multi machine concurrency is somewhat at odds with the serverless future we're moving towards

IMO, that's a misconception. They work at different levels and I wrote a more in-depth explanation here: https://dashbit.co/blog/kubernetes-and-the-erlang-vm-orchest...

Although I agree the sentiment plays a role on adoption, because many ask "why Elixir when I have k8s", while in practice, if you like k8s, you should enjoy Erlang/Elixir. They apply similar principles at different scales.

So I don't think we could have made a dent on k8s, but rather, we should have positioned ourselves earlier within k8s strengths. :)

[iterateoften]

The issue I found myself in is that I agree with you, that Elixirs Actor paradigm is completely different and not comparable to other languages, but at the end of the day, very very very few applications and apps that startups work on need that. Most apps now are trending towards serverless. And most of the world gets by without the “operating system in an operating system” approach of BEAM.

Rust can be massively concurrent without Actors and GenServers.

So while the Actor model / let it fail approach changed the way I think, at the end of the day I found the traditional paradigms to actually be faster and cleaner to the real world applications that made me money.

[davidthewatson]

It's worth noting that the pattern you describe here is an emergent property of programming languages that changes with the era:

http://www.paulgraham.com/pypar.html

Sadly, the culture of programming language choice in commercial contexts has changed a lot in twenty years, but you can replace python with rust or elixir because programming language choice is a good proxy to understanding insight, intuition, and intelligence.

I like python, but if the broad preference mattered, we'd all be running J2EE apps today. My reasons for choosing python around Y2K were as philosophical then as they are now.

Where your argument goes awry is that what matters is how the programming language catalyzes better interdisciplinary team communication. Code tells a story that, the easier it is to read, the clearer the story gets, and that pays unforeseen dividends in development, deployment, debugging, and distribution.

Computer optimization is straightforward by comparison to scaling human commercial endeavors.

“Programs are meant to be read by humans and only incidentally for computers to execute.”

― Donald Knuth

[iterateoften]

Where your argument goes awry is that this discussion is about Elixir. The points you make I did not see happening in the Elixir community so I left even though I was a staunch advocate for years.

Programs are meant to be read by humans. Which is why Python and the bunch are so widely popular across foreign contexts.

Elixir is hard in that context because it introduces a lot of paradigms.

I have had Elixir teams but there is a big big big difference between someone who has done a Phoenix tutorial and someone who understands supervisor trees and genservers.

There are much better languages than Elixir for communicating intention in programs in a way that a junior dev can come in and understand. Especially if you are working with engineers in foreign countries with language barriers.

[weatherlight]

> I have had Elixir teams but there is a big big big difference between someone who has done a Phoenix tutorial and someone who understands supervisor trees and genservers.

Most of the "scary" parts of the BEAM aren't surfaced when using Phoenix. I don't think you are being terribly honest here. Working with Elixir/Phoenix is no more difficult from a academic aspect than working in Python/Django or gasp JS/Typscript/(Front-end framework du jour.)

> There are much better languages than Elixir for communicating intention in programs in a way that a junior dev can come in and understand. Especially if you are working with engineers in foreign countries with language barriers.

If you say something like Go or Python. I'm going to scream, lol. It's just isn't true. Phoenix was voted the most loved web framework in stack overflow's 2022 survey, Elixir was voted second most love language after Rust. A large percentage of the survey takers only had 1-3 years of experience.

[davidthewatson]

Good point. I can relate.

I worked in Ruby on Rails and our particular culture of Rails was not the purity that DHH encourages, but a kind of hipster collection of things like Cucumber, where the intent diverges from reality. That is, we understood the design intent of the DSL barrier-lowering interdisciplinary facade to non-technical people writing tests.

However, that is not what happened in reality. What happened in reality is that only techs wrote Cucumber tests and they struggled mightily with abstractions that had good intent, but bad ROI, given their misapplication.

The constant cacophony of unforeseeable DSL interactions was that team's annoyingly persistent foot-gun postmortem.

[prophesi]

For a Phoenix application, a Ruby on Rails developer will be able to pick it up pretty fast. Usually just takes one or two pair programming sessions going through the full MVC flow with test-driven development and they're good to take on most tasks. Then reading up some of the official Getting Started Elixir docs fills in the gaps, particularly understanding how a Process[0] works, working up to Tasks/GenServers/Supervisors under the Mix and OTP section.

For hires that already know Elixir, I've found the talent pool to be way above the average (and expensive). They're usually senior devs that fell in love with Elixir, wanting to move away from their previous tech stacks or have already worked at an Elixir shop.

[0] https://elixir-lang.org/getting-started/processes.html

[iterateoften]

The discussion is why isn’t it more mainstream not is it good.

Like you said it’s mostly senior expensive engineers. They are really good, but is it worth it? Do 90% of startups need it? I have had success hiring younger inquiring Elixir engineers also, but the question is about why isn’t it mainstream not how to find a diamond in the rough.

If you are running a company today the fact of the matter is Elixir a a executional Risk and the Reward the risk gives clearly isn’t worth it for most startups or else it would have higher adoption.

[HerrBertling]

Really appreciate your focus on economic reasons. That indeed makes a lot of sense.

I guess the gamble to use Elixir/Phoenix only pays off in certain circumstances and if your business grows in such a way that you can simply afford to hire more expensive devs in later stages of the journey.

[mattbrewsbytes]

I would second his opinions and take it a step further ... people here will debate tech stacks til the end of time but in the grand scheme of things picking a tech that has a much smaller and more expensive talent pool could be a scenario where that choice is a death knell for the project (could be, not will be). The low adoption rate also means more abandoned libraries, less variety of libraries and possibly having to DIY things. These all add time to a project on top of a learning curve (which will vary per person) which make it more expensive.

I'm not advocating always pick something with the lowest $/hour rate. There are a lot of other choices out there that are not going to have risks around technology choice.

Long term maintenance is a concern too, not of Elixir, of the apps built with it. When that app goes into a maintenance mode (still providing value just doesn't need new/active development) the devs will likely move on to other work/companies. Now to do support work you have a small+expensive talent pool that doesn't likely want to do support work.

If you're a fan of Elixir, don't take this as me saying "no", I really like the things I learned (and continue to learn) working with it. Its just trade-offs that mostly are on managements shoulders. The developers advocating for it take no risks really.

[brap]

This is an approach I strongly believe in.

For 99% of things, language performance doesn't really matter (it's usually cheaper to just scale up). So you might as well focus on developer experience and hire-ability.

For the 1% where it does matter, drop down to something like Rust, and use the developer-friendly language above as glue.

You see it a lot in Python, where the performance of the runtime itself is kinda crap, but it doesn't matter because it's very developer-friendly. It became the #1 language for high performance data science, thanks to libraries that use C and stuff under the hood.

[pg_1234]

Elixir doesn't offer an easily benchmarkable performance boost the way Rust does.

It does offer a boost, but in the form of system reliability in a concurrent environment. This kind of advantage is seldom properly evaluated until AFTER you have a disaster ... by which time you are typically committed to different stack.

[signa11]

> Elixir has very few engineers to source from.

this : http://www.paulgraham.com/avg.html comes to mind.

[iterateoften]

I guess my point would be that Rust is also could be considered an esoteric niche language with a lot fewer engineers than Python, but I would choose Rust over Elixir because of the benefits.

I think PGs advice really depends on the founding team. Now it’s quite common to have only semi technical founders that make an engineering hire instead of the founder being an engineer, because languages like Python and JavaScript have commoditized the initial CRUD aspects of launching a product.

If your product is more technical and low level it makes sense, but if your building a HTTP SaaS app that connects to a database then chances are the difficulties and differentiation happen on the Product/Design level, and much less so on the engineering level unless you make it big.

[weatherlight]

"A false dilemma, also referred to as false dichotomy or false binary, is an informal fallacy based on a premise that erroneously limits what options are available. The source of the fallacy lies not in an invalid form of inference but in a false premise. This premise has the form of a disjunctive claim: it asserts that one among a number of alternatives must be true. This disjunction is problematic because it oversimplifies the choice by excluding viable alternatives, presenting the viewer with only two absolute choices when in fact, there could be many."

1) There's plenty of Elixir engineers, and most of them specialize in web development or a domain thats web dev adjacent. Python is used for everything, with loose conventions on how to program in each domain.

2) Rust maybe faster than Elixir... but what about things like concurrency across multiple nodes and fault tolerance. Fearless concurrency, etc. also, it's really not that hard to create NIFs in Rust. It's really hard to do the above in Rust.

2.a) for most kinds of developement where both rust, python, and elixir could be used to solve a problem (web dev/data science)..... speed is probably not something you are worrying about.

[pron]

Rust isn't really showing the kind of adoption rate required for long-term success (at least not that exhibited in the past by almost all languages that have achieved long-term success), either. Early adopters tend to be fickle, it seems.

[iterateoften]

Large companies like Meta, Google, etc have Rust as part of their official stack. The market cap of companies that have Rust listed is pretty significant compared to Elixir.

[pron]

Significant compared to Elixir, alarmingly low compared to languages that truly made it. By the way, the moment when large companies start adopting a language is critical. For a language to make it, it must spread like wildfire inside those companies; if it doesn't, that's a huge negative signal to more cautious observers.

[iterateoften]

Not really, Rust can be 1% of the codebase but by Rusts nature it is implemented the most critical paths.

Rust is insanely awesome for embedding. So you can have Python app that 90% of your team works on and embed Rust for the critical parts to optimize.

But I get your point, however Rust is one of the most discussed programming languages in the past year on HN so it must be doing something right.

[pron]

> however Rust is one of the most discussed programming languages in the past year on HN so it must be doing something right.

That's true. It may even be more discussed here than Haskell was five years ago (though not nearly as hyped as Ruby was 15 years ago). Whether or not that's a good sign is up to interpretation, given that HN doesn't have a good record when it comes to market success and HN hype correlation. That's not surprising given that HN is more Vogue/GQ and less NY Times, i.e. it's less focused on what's happening and more on escapist wishes.

[iterateoften]

Not really.

Rust is significantly more discussed than Haskell ever was. Haskell barely ever had more than a couple hundred comments / posts. Rust has thousands.

Haskell was never discussed more than Ruby or Python and you can go to the archives to prove it. This year, Rust is more popular than Ruby and Python combined for discussions on Hackernews.