Is Rails fast enough?
When a new language or web framework pops up, what do you usually see along with it?
Benchmarks. Benchmarks like these.
As a Rails developer, you might be embarassed to see this. I mean, Rails is more than a full order of magnitude slower than Phoenix! And even Sinatra is about 3x faster.
But what do you do about stats like this? Do you shift to another language, so you can get faster response times? Do you move to a different architecture, with some services written in Go, some in Elixir, talking to a frontend in JavaScript? What would you even use Rails for, then?
These days, is Rails too slow to be useful?
How important is performance?
I could give you the generic answer: Don’t worry about it. You should be worried about solving a real problem. Or shipping more quickly. Or writing code you can still understand years down the road. Compared to those, performance doesn’t even make the list.
And I do (mostly) agree with that. But it’s not the whole story.
Like everything else in software development, these decisions are about tradeoffs. Time, money, people, the amount of your codebase you can keep in your head – these are all extremely limited resources. That means you can’t have it all.
Just look at some of the things you could think about when you start a new project:
Speed. How fast can your code run? How many requests can you serve? How quickly can you react to the person using your app? Simplicity. How hard is your code to understand? If you make a change to your data, where do you have to bust the cache? Are you sure? Should you use a faster, but harder-to-understand algorithm? What if you used Sinatra or Metal? Is the extra speed worth losing the ease of Rails? Flexibility. How easy is your code to change? If a new feature comes along, how hard is it to implement? And how much of the system does it affect? Quality. Is your code well-tested? Full of bugs? Is your app easy to use? Do people love it? Safety. Is your app secure? Is your data secure? Will your code explode and lose all your data if it’s used incorrectly? Time. How fast can you ship a “good enough” version? How soon after that can you ship a “finished” product? Fit. Does it solve a problem people have? Will it be successful enough to make it worth building and maintaining? Cost. How much will it cost to build? How many people do you need? What kind of infrastructure will you need, and how expensive will that be? Happiness. How much do you enjoy working on your app, with this language, or with this framework? That’s just a sample. There’s a lot more. And your answers to each of those questions affect the answers to others.
Favoring speed might make your code more complex and less flexible. If you favor flexibility and quality, you might deliver the first version more slowly, but you might have a codebase that’s more pleasant to work on, and you might deliver future versions more quickly.
Even if there were a right answer to each of those questions, it’d take you so long to figure it out that it wouldn’t be worth doing. So how do you decide?
I start with values. Which of these do I feel strongest about? If someone said, generally, without knowing what you’re going to build yet, which one of these would you pick? That’s where I start.
I value fit first, with happiness close behind. (These two change places a lot). If I can’t ship something that solves a real problem, I have a hard time seeing the point of building it. And there are so many projects you could work on, that I don’t understand working in a language or on a project that makes you unhappy.
From there, I favor simplicity, then quality, then time, and so on. Performance is pretty low on my list of priorities, especially in the beginning. I’m not saying I don’t care about it. Just that, generally, it drives fewer decisions.
When you see things that way, it’s no wonder I’m a fan of Ruby and Rails. They make me happy to use, because I feel incredibly productive. I can solve problems without feeling like I’m fighting the language. It’s the easiest, fastest way I know of to try crazy ideas in a totally realistic, production-ready way. And the faster I can ship and iterate on ideas, the more likely it’ll be that I’ll narrow in on fit. Rails fits my values, so its problems don’t seem as bad.
But that’s me. Which of these do you value? I have my opinions, but reasonable people differ, and my values may not match yours. Performance might be more important to you, or Rails might not make you as happy as it makes me. If that’s true, you might be happier in a different language or framework.
But whatever you decide, it’s important to know on what you value. Where do you fall on each of those properties? How do you trade them off against each other?
That’s what defines your personal dev culture.
After you understand that, it’s easier to find a team and project that match. And when you can work with the right people, on the right projects, with tools that match your values, it’s like falling in love with programming all over again.
Thanks for reading, and have an awesome day! Justin