I’m a 48 year old developer and entrepreneur. I’ve developed professionally in C++, Java, Python, C#, Ruby, Go, and JavaScript. My current startup and my previous one were both built on Rails. Here’s why.
As an entrepreneur, my definition of “speed” is “the amount of time and money it takes to reach an objective”. Code execution speed sometimes matters, because I want happy users. But once the app is fast enough, being faster doesn’t help much. Fast means “fast enough to get the job done”.
Hiring for Rails
Once my company moves beyond the initial prototype, adding more developers is the primary way that we can accelerate the engineering team. Our ability to recruit and hire great developers is driven primarily by the talent pool and by the morale of our team. Talent pool is the first reason why your company can be extremely productive in Rails. The are a lot of developers out there who are skilled in it! And skilled developers who don’t have previous Rails (or Ruby) exposure, can pick it up quickly. The second factor in hiring a great team, morale, is driven in turn by two factors: company values (sometimes misnamed “culture”) and success. It’s often been noted that the company values are a reflection of values of the founding team. In my experience, this is true. “Success” is driven by the aforementioned “speed”. Success comes from quickly acquiring new users, making them happy with new features and bug fixes, supporting and them through problems. The more the team succeeds in doing this, the happier we are. And the happier we are, the easier it is for us to grow.
Coding for Rails
That covers the team aspect. Let’s switch gears and talk about the code base itself. I’m the CTO, so my world revolves primarily around the product code. I think it’s fair to say that successful startup code bases go through three phases:
- Prototype (5,000 lines)
- MVP (50,000 lines)
- Maturity (500,000 lines)
Note that in each phase, 90% of the code is new. That means you can rewrite the entirety of what you already have (in a new language if need be) and only take 10% longer. Less, actually, because you’ve already done it once before. Rewrites are fun and easy! Too bad it doesn’t often make more business sense to do them…
When we start a company, our goal is to get to that 50,000 line MVP. To get there, we need to meet business objectives like acquiring and satisfying users, and growing the engineering team.
The job of the code base is primarily to glue other frameworks, libraries and services together. We don’t have time to do anything else! Rails (and some non-Rails Ruby) is a great platform for building that glue. It doesn’t really have to do very much work. The work should be happening elsewhere; in the database, on the frontend (where compute power is free!), in native code like JSON libraries and database drivers.
So, back to speed. The job of the programming language and framework is to turn your team’s ideas into an MVP as fast as possible. Ben Halpern, founder of Dev.to, puts it perfectly in his blog post “I’m Ben and I am a Rails developer”:
I recall a blog post about a new company that had some
non-technical momentum which was completely derailed by
taking a simple idea and writing it in Go microservices.
I cannot remember where I found the post, but the story
was telling. They scratched their work and took a week
or two with Rails to make up for months of lost
productivity overthinking the problem.
So keep in mind: to a developer, speed means “performance on benchmarks”. The Ruby 3x3 benchmark and all the debate around it has once again brought out the Ruby critics who are reminding us all again how “slow” Rails is. To me, speed means productivity. Speed means telling my CEO and our investors that we are on track with the product milestones, and on-track with user adoption targets. Sometimes, there is legitimate performance showstopper in the app; a slow query, or a scaling issue with large data files. When that happens, a good engineer digs into the problem for a couple of days, solves it, and we move on. In Rails!
Key takeaways
In summary, as a startup CTO, my job is to coax the most “business speed” out of the dev organization as I can. Rails gives me speed, because:
- There is a lot of great talent available.
- Ruby is optimized for developer happiness, and happy teams are better teams.
- Rails is productive, and the second version of any Rails app is going to be faster and better than the first version of the same app written in any other language.
- The job of a framework, like Rails, is to glue other tools together. 80% of the program execution time should be spent outside of Rails (say, in the database). So making the web framework 2x faster only makes the app 10% faster. Optimize elsewhere.
That's why I build on Ruby on Rails.
- kevin
While you're here
We are conducting a survey: State of Software Architecture Quality. We are aiming for 300 responses, and once we meet our goal we will be donating $1,000 to Girls Who Code. Please contribute to our understanding of software architecture quality by filling out the survey! Of course, we will be summarizing and publishing the results once they are available.
If you don't want to fill out the survey, but you want to be notified when the results are available, you can fill out this form: https://forms.gle/u8CPS3GGD6A7WHsG7.
P.S.
I suppose I am trolling a bit by calling Rails the “world’s fastest web framework”. This is prompted by two things. (1) The kerfuffle over the Ruby 3x3 objective. (2) The degree to which developers will under-value their own time. As rhymes puts it:
the old saying “premature optimization is the root of all evil”
applies also to technological choices.
Latest comments (23)
There's also just the bitter reality that most of us will never build a site that has the volume of traffic and users of Github, Airbnb, etc (who, incidentally do use Ruby). So the point about performance is probably not relevant for the majority or even almost all developers who build ruby apps in the first place.
What I see happening typically is that when the Ruby application does hit that magical hypergrowth period, developers/the company has a lot of pain, and then rewrite some of the application in Go. Not all of it, not half of it, not even 10% of it, just the parts that need to be super performant.
That doesn't negate all the benefits that using Ruby provides, imo.
It's possible to be incompetent in any language. English for instance.
is there any benchmark that confirms the articles, techempower.com/benchmarks/#sectio... according to this ROR is no where near
I think Ruby and Ruby On Rails should be compared against low code or no code solutions (because the amount of abstraction that it's there) not against super scalable functional programming languages like Elixir. And speaking about the resource hungriness of Ruby, when your product reaches market and hopefully financial success the costs of the cloud bill won't be a problem.
Brilliant article! Thanks!
Godspeed.
I can programming C# and Ruby, I think I wouldn't consider C# jobs even a little bit higher paid. Using Rails is really peasure.
Good post!
I gave up trying to learn how to use Rails when I could make heads around of just using the frame work. But I use Middleman
I find it particularly interesting that the critics of rails leave off basecamp, hey, and many other big pieces of software that are powered by ruby and are doing just fine. Granted I don't know how large their user base is, but I do recall seeing DHH tweet about rails being able to at least power a $100m company(basecamp) and now an email service. Im guessing rails is plenty fast enough for those.
Thanks for a great article. I'm new to rails (a couple of months in) and I'm enjoying every minute of it.
The "machine" cost is no where near the "human cost". Unless you have a very specific case (to which you should optimize), there is no need to rewrite anything in X. Hiring additional people that knows X will eclipse whatever you are going to save by using fewer machines.
At the end of the day, the bigger bottlenecks are Databases and disk I/O.
Curious about this - how often is language the bottleneck (and the cost driver) vs. database and just a poorly optimized codebase (N+1 queries, bad SQL, etc.)? What have you measured?