Ruby companies like AirBNB, Stripe ended up edging out their competitors using the relatively glacial Java or C++ frameworks. We will need to see a new generation of Phoenix winners before Elixir is taken seriously.
It could be that the marginal performance gain from using Elixir is not worth the hassle of training and hiring in a whole new language. It remains to be seen.
Just a small nit-pick here. If we're talking REST/graphql stateless APIs, sure the scalability gains may be a harder sell vs throwing hardware at the problem, but the value-add depends on what's being built. I built Phoenix first and foremost for real-time, stateful web applications. So anything that requires websockets, frequent updates, PubSub, presence, etc, you will be extremely hard to match what our stack provides out of the box, performance wise, and distribution wise. Not everyone needs these things but increasingly companies do, ie chats, social feeds, dashboards, and now LiveView-like interactive applications all change the equation from "marginal" perf gains.
I am an Elixir evangelist, to be clear, but it's one thing to have believers and another to change the world. I think you are right that Phoenix will eventually win the day in regards to real-time, stateful Web applications. "Traditional" REST APIs may be a harder sell, and perhaps Elixir doesn't need to eat the entire Web to considered successful. There are still many Java developers at work after all.
I am really confused by this comment. "Companies leveraging a quick to develop in, batteries included framework, with really poor performance, beat out companies using highly performant but less quick to develop in languages/frameworks, is reason why I'm suspect about a quick to develop in, batteries included framework that also prioritizes real time communication, with quite solid performance, and really predictable latencies".
I mean...the argument about "the hassle of training and hiring in a whole new language" applied just as much when Rails took off. While Ruby had been around since the mid-90s, it was definitely an esoteric language for the decade or so prior to Rails.
Will Phoenix penetrate as broadly as Rails? Probably not, since Rails already exists, and now benefits from having a lot of people who know it. But being able to reduce hardware costs by 90% while giving up little of the flexibility, and bundling in a lot of real time features can be quite compelling; we'll just have to see.
> Will Phoenix penetrate as broadly as Rails? Probably not, since Rails already exists
I hope it does one day, but not to replace Rails.
It's a really hard sell because I think eventually we're all going to converge to the same real-time, low server cost setups. At this point it becomes how fast is it to build my app and what is it like to maintain it.
Rails 7 is coming out with a neat feature that will build in encrypted fields at the DB level for Active Record with a way to situationally decrypt them in case you need to debug something specific in production. Then, any time a developer accesses those decrypted fields an audit log will be generated. It'll also audit log any Rails console access[0].
These are really big things to not have to deal with. Will Ecto ever get this sort of thing? Maybe, maybe not. But I think the bar is raising overall where if things like this aren't added in the future you have a less chance of being adopted by the masses because not everyone has the resources to spend months developing stuff like this in house.
Did we exist without it in the past? Absolutely, but I think we need to be comfortable with adjusting our expectations that higher standards are coming as there's more framework competition and languages coming out. LiveView is a great example of this, only a few months after it was announced a bunch of popular frameworks released their take on it that play to the strengths of that framework of choice. Now there's kind of an expectation that it shouldn't take an SPA to develop a mostly document driven application with a nice user experience.
Personally I would want features that help me build apps faster and more securely while having to pay $40 / month to host my app instead of a framework that doesn't have these features but it costs me $20 / month to host it instead. Sure if you take this to completion and say but if you have 10,000 servers running it's double the cost but for most applications you can host a pretty popular and profitable app for less than $100 / month with any modern tech stack without making performance compromises (ie. <= 100ms page responses for the p95).
Stripe, Shopify and GitHub are still largely relying on Ruby as far as I know (and while there are reimplementations of some of their services in some languages, I don't think C++ or Java have been publicly mentioned often).
That said, I think one important asset of Elixir (in my view) is not the raw performance, but the overall "total cost of ownership" (including maintenance work, and software is a lot of maintenance).
Being able to simplify architectures is something that is nicely done with Elixir, actually.
If a part of an app needs to play a "proxy" role (like here https://github.com/etalab/transport-site/tree/master/apps/un...), then I just add a component to the app, and I can keep the incoming connections under hand, all while issuing external queries etc.
If there is a need to do some rich interactive dashboards, I can use LiveView.
If I need to demonstrate some simple stuff, I can use "Mix.install" to create one-off scripts.
If I need to do more data-science, I can tap into LiveBook, VegaLite etc.
All this with a small team or as a solo developer, is quite great, much more than raw performance, in my eyes.
Technically "marginal" refers to the gains made by an incremental improvement, in this case the adoption of Phoenix over Rails, and not the use of Phoenix over nothing at all. So we still refer to the gains from Phoenix as marginal, even though they are substantial in many cases.
It could be that the marginal performance gain from using Elixir is not worth the hassle of training and hiring in a whole new language. It remains to be seen.