this : http://www.paulgraham.com/avg.html comes to mind.
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.
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.
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.
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.
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.
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. :)
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.