Speaking as someone who uses Rails regularly, I agree - it is considerably slower than many other language choices. It probably isn't a good call for a performance critical bottlenecked service that can't scale horizontally.
For everything else, it's great, and it's almost always a good default to choose speed of development and engineer productivity over runtime performance.
> For everything else, it's great, and it's almost always a good default to choose speed of development and engineer productivity over runtime performance.
Doesn't Elixir on Phoenix[1] provide the elegance of Ruby on Rails without its drawbacks?
> Doesn't Elixir on Phoenix[1] provide the elegance of Ruby on Rails without its drawbacks?
I'm not sure I would say elegance is the main feature of Rails, but I think productivity is. IMO nothing out there beats Rails in terms of productivity on a new project. Phoenix is clearly inspired by Rails, but if you'll permit me to pull a semi-random number out of my ass I don't think Phoenix will ever be able to do better than about 80% of Rails's productivity. Some things are just not as simple (for example, just due to the nature of things Ecto is not as simple to write with as ActiveRecord is).
That said, I've totally moved away from Ruby on Rails and over to Elixir/Phoenix for my stuff. I absolutely love Elixir. So far in my experience I'm finding it more performant, easier to maintain, but a little less productive to write in. But still plenty productive enough.
> I don't think Phoenix will ever be able to do better than about 80% of Rails's productivity.
I haven't used Elixir/Phoenix myself, but my main issue with Ruby on Rails was how much of long-term productivity was sacrificed for short-term productivity gains.
In other words, what made it extremely easy to create the first version of the application with Rails, also made it very hard to maintain and scale it later on.
Therefore, I would consider it a win, if 20% decrease in short-term productivity provided an equal increase in long-term productivity, which is much harder to measure.
I think you’ll have to spell out specifically what those things are that affect long term productivity if you’re going to use them as a argument against use of Rails.
I not saying your wrong, just that a hand wavy “rails is bad in the long term” is not an argument.
> Phoenix will ever be able to do better than about 80% of Rails's productivity.
It took me 4 hours to learn LiveView, 3 to get it up and running with Phoenix PubSub (which I didn't know before either), and another 2 to get Presence in there. So I now have a live dashboard for the backend of our service (and it will probably be similar to the frontend). The rest of the week was developing a system so that I could run acceptance tests concurrently (you have to shard your Registries and your Channels and use a secret erlang feature to track who's what). Everything "just worked".
I think this 10 hour enterprise would have taken me at least a month to do with a standard RESTful interface and a backend off the shelf PubSub like RabbitMQ, and probably two months to do with an non-featureful backend websockets system (I find websockets confusing).
It's hard for me to believe that any other system is as productive.
I'm pretty much all in on Phoenix, but I suppose a good reason to stick with RoR would be that 1) it's easier to find (experienced) devs, and 2) there are (still?) many more packages available which can make quick development easier.
Our research has indicated that Elixir has basically stopped growing in the general market.... really only getting any growth from converted erlang devs.
Have you seen anything different? Most enthusiastic vendors I’ve talked to have moved away from elixir due to low adoption and demand.
Tiobe, google trends, etc tell the same story.
I’d love to find evidence to the contrary but the low numbers of elixir devs seems to be both a supply AND demand problem... ie lack of traction and interest.
I'm not on much of a 'market' and use Elixir/Phoenix for clients when I expect that either I will be primary on the codebase, or that I'll be training someone to take over.
In the latter case, I feel confident enough about Elixir that I'd train someone to use it rather than opting for a more 'mainstream' stack.
I suppose if getting new developers on-board asap is a concern, Elixir might not be the best choice. But personally if I ever were to build a product that would eventually need more programmers, I'd pick Elixir even just for the 'filter' effect. It's easy enough to pick up for a good developer, but would filter out many of the shittier devs I'd encounter if I went for PHP/Python/Ruby. and the benefits are worth it to me.
All that aside, while I am not confident that Elixir will gain much traction, I think there's a small chance LiveView and Telemetry, among other projects, might divert Elixir from the path that, say, Clojure, seems to have taken when it comes to traction.
Hex.pm (Elixir + Erlang) currently has 8900 libraries. Compared with Ruby's 155000 that's one big drawback of choosing Elixir. Add to this the mature Rails infrastructure and community resources there's definitely a trade-off.
While I agree that library number is an okay barometer of community health. I'd also look at age of packages and latest commits to gauge a trajectory. Furthermore, if I found the packages I needed to accomplish most tasks (auth, task scheduling, message queuing, database, logging, serialization) and those packages were of good quality, does sheer number even matter at that point? I'd say when looking at Elixir's community health vs something like Nim or Crystal, it's in great shape. (and I'm not wiling to call either of those languages "defunct")
For everything else, it's great, and it's almost always a good default to choose speed of development and engineer productivity over runtime performance.