DEV Community

loading...
Cover image for Ruby on Rails is the world’s fastest web framework for startups

Ruby on Rails is the world’s fastest web framework for startups

kgilpin profile image Kevin Gilpin Updated on ・4 min read

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”.

Built on Rails

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.
Enter fullscreen mode Exit fullscreen mode

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.
Enter fullscreen mode Exit fullscreen mode

Discussion (28)

pic
Editor guide
Collapse
sharpninja profile image
The Sharp Ninja

Do you stick around long enough for the huge cloud bill when reaching critical mass to keep all that Ruby power running? How about the bill for the complete rewrite in a compiled language because your hemorrhaging users (and revenue) because the app is unusable during peak times?

Collapse
abhinaykumar profile image
Abhinay Kumar

Do you ever reflect on your negative comments? Someone is taking an effort to make us understand that productivity is the kind of speed that devs should care about period.

Collapse
sharpninja profile image
The Sharp Ninja

Yes, I do and that's why I respond. Productivity is only achieved through a positive result. If your goal is short term (ie, reach the MVP, get paid then get out) then by that definition Ruby would be productive. If your goal is creating a sustainable company that is a good steward of investors assets as well as customer assets, then Ruby is counter-productive.

Thread Thread
kgilpin profile image
Kevin Gilpin Author

When you achieve MVP you don’t get paid. You get to borrow more money (from VCs usually), which you can use to try and scale up your embryonic company. Meanwhile everyone is trying to kill you.

Thread Thread
sharpninja profile image
The Sharp Ninja

This is usually the point where the founders pay off the loan they made to the startup and give themselves a nice paycheck. Nothing wrong with that, just need to keep in mind the motivation to get there is not small.

Collapse
ronald_arias profile image
Ron

Uhmm my understanding of the article is that you use Rails to get you started, but then you optimise.
I've taken that path myself, started with Rails and as demand grew we slowly spread into microservices across different languages. Twitter, Github, etc all did that.

Nobody is saying you stick with Rails forever. Some companies maybe don't even make it that far to reach performance issues that require badass infrastructures.

Collapse
bizzibody profile image
Ian bradbury

@ron - I think GitHub is ROR.

Thread Thread
ronald_arias profile image
Ron

The GitHub site is still RoR but many of the services behind are not anymore. That's the sort of hybrid approach I'm taking about

Collapse
chazelton331 profile image
Cliff Hazelton

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?

Collapse
sharpninja profile image
The Sharp Ninja

Language benchmarks show Ruby 3 to be about 30x slower than the fastest language (C++). Rust performs nearly identical to C++, with C# being around 2x slower than C++ can JavaScript in NodeJS being about 4x slower than C++. Interestingly, NodeJS performance has steadily improved while Java hasn't and is now nearly a match for Java overall. These benchmarks are of course a very controlled set of programs and situations tested and don't measure things like the scalability of the various runtimes with different types of workloads, such as web apps.

Looking at the TechEmpower website benchmarks, Ruby on Rails ranks #377 in performance and is capable of handling 1.2% of the total load that the fastest platform (Drogon with C++) can handle on the exact same hardware and operating system. By comparison, straight ASP.Net Core handles 60% of the load of Drogo and the best NodeJS can accomplish is 19.9% of C++/Drogon. What does this tell us?

Taking ASP.Net Core as the baseline for realistically finding developers in practically any market, then let's look at Salaries. Based on Stack Overflow's 2020 survey, C# devs make $110,000. JavaScript devs make $112,000. TypeScript devs make $120,000. And Ruby devs make $130,000. As of today, February 14, 2021, there are over 33,000 C# jobs in the USA on Indeed, while there are only 15,000 for Ruby. The fact that there are fewer jobs, yet they pay more, means supply of programmers is much smaller, so filling those Ruby jobs will be more difficult and costly.

So, to implement your MVP in Ruby will cost more, will be more difficult to find developers, and the product will be 30x slower that doing it in ASP.Net, which means you will be adding cloud resources more quickly and frequently if you reach Unicorn status.

And then, when you do decide to start hiring devs to replace Ruby code with something saner, you will be fragmenting your skillset among teams and lowering the agility of your organization whereas C# can be used for everything from stored procedures to automation scripts to backend services to Server-side Rendering AND Client-side rendering of web apps which gives you freedom to let folks move around and wear different hats and find their niche within your organization instead of losing experienced devs just because they are bored or dissatisfied with their current team.

Thread Thread
ericguo profile image
Eric Guo

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.

Collapse
defman profile image
Sergey Kislyakov 🇷🇺 🇺🇸

@ben , could you provide some light on that point? Dev.to uses Ruby and I think it's a pretty high-loaded website.

Collapse
leewynne profile image
lee

Is there a story behind this?

Collapse
sharpninja profile image
The Sharp Ninja

It's simple math. If your app needs 100x the computing power to serve N concurrent customers, then your cloud computing costs will be about 100x higher. And many startups that began on a Ruby MVP paid large sums to rewrite on a sane platform to get those costs back under control.

Thread Thread
bizzibody profile image
Ian bradbury

Where did 100 come from?

Thread Thread
peerreynders profile image
peerreynders

Benefits of Elixir: How Elixir helped Bleacher Report handle 8x more traffic:

"On our monolith we needed roughly 150 [Rails] servers to power the more intensive portions of BR. Following our move to Elixir we're now able to power those same functions on five servers and we're probably overprovisioned. We could probably get away with it on two," Marks says.

Then again Phoenix/Elixir/Erlang are a special kind of beast.

That's 'Billion' with a 'B': Scaling to the Next Level at WhatsApp
Why We Chose Erlang over Java, Scala, Go, C

Which companies are using Erlang, and why?:

Once upon a time, Cisco, Ericsson, Klarna, Goldman Sachs, T-Mobile, WhatsApp, Amazon and many other top companies kept a secret. Erlang was that badly kept secret.

Robert Virding:

Well then, just more cases where it's in wide use but you don't see it or know about it. It's really great it's being used but a bit depressing that no one knows about it as you continually hear "what's Erlang, why should I learn/use it as no one uses it?"

Second-Order Effects: Energy Hogs: Can World’s Huge Data Centers Be Made More Efficient?

Collapse
andevr profile image
drew

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.

Collapse
brodock profile image
Gabriel Mazetto

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 than 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.

Collapse
nidistinct profile image
niDistinct

the Ruby critics who are reminding us all again how “slow” Rails is. To me, speed means productivity.

Thanks I'll remember this

Collapse
haruanm profile image
Haruan Justino

Those are almost the same reasons that I use Django with Python, I will save the article to read again in the future, quite nice things to remember.

Collapse
famouslabs profile image
Sky 💎🙌

Hypetrace.com is also built on RoR and we are currently hiring! 👋

Collapse
tomavelev profile image
Toma

The speed of coding/bug fixing depends on the skills, experience with the programming tools - of the coders /and their attachment to technical perfection from machine viewpoint/. Besides that note, I totally agree with you. Speed of development is more valuable than of execution.

Collapse
azuaraj profile image
Antonio Azuara

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.

Collapse
andyobtiva profile image
Andy Maleh

Brilliant article! Thanks!

Godspeed.

Collapse
sujitmohanty profile image
Sujit Mohanty

Great article! Thank you!

Collapse
muzammilaalpha profile image
muzammilaalpha

Good post!

Collapse
joshuawoodsdev profile image
JoshuaWoods

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

Collapse
sahasrara62 profile image
prashant rana

is there any benchmark that confirms the articles, techempower.com/benchmarks/#sectio... according to this ROR is no where near