Can you say which website it is, just out of curiosity.
I’m not trying to disprove your assertion but when I used Rails four or so years ago I had some problems when running in AWS, where the app just kept consuming memory without doing anything substantial and I had to restart it every other week.
And could you tell me what is the hosting service for the server?
Sure, it’s https://gorails.com. It’s hosted on DigitalOcean.
I chatted with its creator on how he built and deployed the app at Learn Ruby on Rails through Screencast Tutorials on GoRails — Running in Production Podcast 12.
Also recently had a lead developer from https://podia.com on the show who also uses Rails. They are basically Shopify except for course creators. It runs on a few Heroku dynos. They weren’t able to publicly share exact traffic figures but it’s a legit company with 8 full time engineers and 20+ employees.
I think Elixir and Phoenix bring a lot to the table with their own set of advantages but I don’t think it’s fair to put down Rails and other frameworks because they “can’t scale”.
Sorry, it was not my intention to “put down” Rails and you’re right: one can of course build a successful business on Rails and it certainly can handle a non-trivial amount of users.
I was rather thinking about examples like The Bleacher Report, which replaced 150 Rails server with just 5 Elixir server. You most certainly won’t need this level of scalability when you build a product, since very few products will ever become this successful, but just knowing that you could is certainly reassuring.
It’s completely fair to state facts. On a $5 DigitalOcean VPS my Phoenix app was able to handle ~1500 reqs/s while a Rails app struggled with 200. Without caching. Both were nearly identical (the Phoenix app even had several more endpoints; it was a rewrite with a side-by-side performance comparison so the measurement conditions were nearly perfect). And that was 30 months ago.
Rails was just slow for a long time, compared to many other dynamic languages. Maybe this has changed lately? Even if it did, that still doesn’t change history.
Rail is fast enough. From DHH:
Elixir’s advantages are developer ergonomics, latency in stressed situation, and resilience to errors. For the last point, I just found my app has a silly bug that trigger at least every hour and crash some vital part of my app. This has been going on for a month, and I did not find out until I read the log file.
that may depend on the use case.
I’m not sure if it matters a great deal whether Elixir has great performance characteristics or not when it comes to longevity. Onward maintainability, readily available learning resources and developer productivity are all much more important if you ask me.
Whenever a technology decision is made, risk is involved. Choosing Elixir is riskier than a vanilla-but-perfectly-good choice for most people, especially I suspect at larger companies. But that’s OK. The the only way we can ensure the success of the community in the future is to take that risk!
I’ve been gradually writing an article about what it’s been like as an early adopter of Elixir at our company. It’s been a mixed bag as you might expect but I still believe it’s the right choice. In my opinion the single biggest thing that we should work on as a community is great library support. Where library support exists it tends to be good, but I’m sure we must all have experienced dead open source repos with non-responsive owners or complete gaps in support.
Please no-one say “all you have to do is fork the dead repo and create your own” :). Yes I know that! That’s a luxury of time that I think many won’t have.
Sure, but that’s relative to one’s needs. I also know local e-commerce owners for whom a $10 WordPress website + a few extensions is good enough. And those sites crumble with 30 concurrent visitors.
And their stack is still good enough.
I was however addressing the “unfair” statement that Rails is slower than Phoenix. Which it absolutely is.
I agree with you. My point is more about how to “sell” elixir/phoenix in your org. You can do it in 2 ways:
I am not a sales person but sometimes I play one. The second way is usually more effective
Very much agreed. Elixir helps us manage that mental load so we can concentrate on features. That’s a primary attraction for me!
All that it took to convince me that Elixir will still be thriving for many years to come (applies to Phoenix as well), is having used traditional concurrency primitives like threads in Java, and even async/await to some extent and then having used the OTP model. It just blows everything so far out of the water that it’s by far the easiest, safest, and most fault tolerant way to do concurrency, which is notoriously one of the harder things to get right. Maybe that doesn’t apply to a CRUD web app, but Elixir makes something that’s typically hard very easy, and to me that means that it’s going to keep succeeding.
Latency would be an important number to have, especially the p95 case because if all you have to measure is requests per second and it’s an even distribution of sequential traffic that would be:
If you can do that with Rails on a $5 / month server I’d be really happy. If only a tiny fraction (way less than 1%) were paying customers you’d be making millions of dollars a year from that Rails server.
I think to convince the masses to leave what they’re currently using we need more than just raw performance because Rails and other frameworks really are good enough in a ton of cases in the performance department.
You are shifting the goal posts. I never said “200 req/s is not enough“. I said Phoenix has more, and has better latency too. We’re talking objective metrics and I’m sharing mine:
It was an extremely average, boring, CRUD app with some extras, exactly like those you seem to prefer as a litmus test for a web framework. Those projects have almost no time/money budget for technical excellence and I’d argue that most Rails apps out there could easily be 2x - 5x faster if they could get that budget. So undoubtedly, some of Rails’ reputation for being slow is undeserved.
But my argument here was: with as close to the defaults you could get away with, what’s the best that the framework can do?
Phoenix clearly won on that metric in my experience since I’ve rewritten two Rails apps to Phoenix from scratch and have the observations.
I don’t see a reason to shift the topic to “but do you REALLY need more than 200 req/s”.
Agreed. If your bottom-line is req/s, then the counter-argument is that people can always throw more money at the infrastructure. Unless you are running at a massive scale where reducing to 10% of your infrastructure is going to save you millions - but at this point it becomes a much easier argument to make anyway.
And even req/s is the wrong measurement here. What is the time your development team spent on doing optimizations to get (or to keep) those numbers? Or how many hours were spent debugging issues in production because you forgot to expire cache key XYZ? How slow is development because to implement the smallest of features you need to touch 4 or 5 different architectural components? What is the size of your devops team because your infrastructure is 10 times bigger than it could be elsewhere?
All of those costs are going to rack-up faster than your operational budget - but unfortunately they are not as straightforward to measure.
And there is no technology that scales forever. If your business is always growing, one day you will have to face the scalability demons, regardless of the platform. With Elixir/Phoenix, you will be able to postpone this fight much longer than in other stacks. The platform is more versatile and robust too. I have literally seen other stacks crumble because they started talking to external APIs which dragged everything else to a halt.
So if development time is key, the promise with Phoenix is that your team will stay productive and focused on your business domain for much longer. This is specially important for smaller teams where setting someone aside has a bigger impact on product development. The tagline is “Peace-of-mind from prototype to production” for a reason. 
A big part of the appeal behind LiveView is aligned with this: it is less operational and development complexity. Especially for smaller teams. And recent additions like the new auth generators are there to help you hit the ground running.
I don’t believe he is shifting the topic. His point is that, if your argument is that Rails could do 200 req/s, then you are not making a strong case for a lot of people, as 200 req/s is going to be good enough. The question is how to convince people to migrate even when they are not expecting 200 req/s at all.
If you trace a bit above you’ll see that he did make a detour to the performance side. I was mostly responding to him there but yep, that’s not what’s the main topic here.
I completely agree that performance is way down the priority list on how to convince people that Elixir will be around in 5 years and will have a thriving community.
Elixir will thrive as long as the talent stays engaged. And right now the talent in the Elixir community is just great. Incredible track record of innovation and sustained progress.
Worst thing that could happen is if Elixir suddenly became super popular and suffered mass adoption by second-rate devs, as befell Ruby/Rails.
@pedrogarrett if your management can’t/won’t understand the advantages of the beam ecosystem for themselves, you should leave. Nobody should associate with leadership that charts direction by Stack Overflow surveys.
Best progress comes from small teams who are highly focused and technically engaged. This is what Elixir has. Being small is a critical feature, not a bug. May it last long.
Don’t break your back trying to convince laggards or FUD-peddlers of anything. Instead spend your energy to find a like-minded team with whom you share vision/harmony/energy. Join them and knock it out of the park.
I moved to Phoenix/Elixir because I could not solve easily RealTime problems with Rails.
I stay because…
It makes my dev experience so much easier, and my code safer.
But it is a steep learning curve, and if You skip this part, You will always be blocked, trying to fit your old code in a new paradigm.
Almost every developer starts out being ‘not very good’ Andy, but with perseverance and determination they get better and better over time. In fact this very forum was in part set up to attract and accommodate more ‘less experienced’ and everyday developers as I had felt that Elixir appeared to be primarily made up of more experienced devs and I knew this would be off-putting to a lot of developers who make up the bulk of the mainstream.
So a large influx of devs at this level has actually been a blessing and a huge reason why Elixir has been able to become so popular - so we have a lot to thank them for 
(And just for anyone reading who might need to hear this, all genuine and sincere developers, no matter what level you may or may not be at are welcome to join our community here 
(the only people we’re not really keen on, are the rude/condescending types)).
Aston - this is your forum, I respect your stewardship. If you want to edit my language to fit your sensibilities I’m ok with that.
Elixir is high innovation. Actor Model, Metaprogramming, Channels, LiveView, Nx, Broadway, etc. Absorbing all the new concepts is not easy. I believe the people who are best suited for Elixir today fit an early adopter profile, risk tolerant and high enthusiasm. It’s not for everyone.
Many new Elixir devs are now community leaders. Success requires energy and commitment, not necessarily years of experience.
My message to beginners would be: if you’re an early adopter and enthusiastic about BEAM, Elixir gives the best environment to learn and grow, the best platform to make a breakthru.
But if you don’t fit that profile, maybe it would be better to stick with a language that is more popular and less demanding, wait a few years and see how things develop.
Selling a rewrite is always hard, because it’s almost never justified. If you can bring your team to believe in the benefits of Elixir, I think the best approach is to choke rails off.
Create strongly defined barriers for Elixir and Rails. Connect the two of them, and piece by piece move things over. We did this, and found Elixir was fast enough as a reverse proxy to rails that we didn’t really notice the performance hit. You could do a similar thing with something like Kubernetes Ingress routing too, or countless other cluster networking tools.
If your team’s committed to the rewrite, then this offers a much smoother path to release. You might even find that Rails can keep some of its old jobs as you realise that it’s not worth porting everything.
This worked successfully for us, we took advantage of Elixir’s strengths - realtime systems, exceptionally fast template rendering, LiveView - but have kept our Rails system around because it works, and ripping out a bunch of stuff has made it much more contained and easy to work with.
© Copyright Elixir Forum | Terms | Privacy & Cookies
