Hacker News Reader

Comment by davidw | Hacker News Reader

> Rails remains to this day the tool I go to for building web applications because it's so well suited for building something quickly. Sure the effort to make it scale is present but I see any scaling effort as big regardless of framework or language.

This is why I continue to use Rails despite being interested in this that and the other new thing. It's very productive in terms of getting something up and running.

I mean, heck, Twitter started with Rails, and despite some hiccups, managed to grow. And Twitter is pretty much the poster child for something that has to scale massively. Odds are, you won't have the same problem.

View on HN

Twitter is the poster child for dumping Ruby.

Even if Rails is God's gift to CRUD app prototyping at some point you have to ask if building a tech stack on something that is going to fail hard as soon as you get popular is providing a good service to those who are paying you for the quality workmanship.

That was not what the commentator was referring to; > "It's very productive in terms of getting something up and running."

Implying that Twitter reached success under Rails, even if it was _not_ the best fit for the problem set.

Dumping Rails when you have won the market is a nice luxury to have, one that most people on HN do not have.

Exactly, and it needs underlining and saying again and again: it's very, very unlikely that your app will ever need to scale like Twitter.

Getting to market quickly is often more important than contemplating about handling Twitter like traffic.

Also, I haven't heard of an application that never had to be rewritten partially/optimised after X years in production. Some problems just don't present themselves in the first couple of years.

Your statement is too cautious. At the start of a project, getting to market quickly is VIRTUALLY ALWAYS more important than handling Twitter-scale traffic. People are simultaneously confident their idea will be popular and afraid of failure, so we have a strong tendency to over-engineer for scale.

If it does scale, don't be surprised if you have to toss out your v1 and rebuild. The difference between a good framework and a bad one isn't about whether it survives scaling; it's about the details of when it fails, how it fails, and whether you can fix it incrementally or if you're signing up for a rewrite-while-hair-on-fire.

Exactly, in fact in the last six months I've been rebuilding a mobile app backend in Rails actually, as a v2. v1 was an MVP built on Parse.com.

> it's about the details of when it fails, how it fails, and whether you can fix it incrementally or if you're signing up for a rewrite-while-hair-on-fire.

So the important questions are:

1. Does Rails performance degrade gracefully under load?

2. Can you gradually shift away from a quick-and-dirty Rails-based implementation to something more scalable without the dreaded "rewrite-while-hair-on-fire" scenario?

In my experience, the answer to both of these is 'no'.

(But these challenges are hardly unique to Rails.)

Given the example of Twitter I'd say that the answer to the second question is yes. They rewrote the Ruby (not Rails) backend and continued serving tweets. Did they have theirs hairs on fire? Maybe, but I don't think you're never in hurry when you rewrite parts of a popular service.

About question number one: no idea, but you can add more machines and scale horizontally. Then you might ask if you want more efficient code between the web server and the database. You can optimize up to C. Finally, Twitter is still using Rails for the front end AFAIK, so it shouldn't be so bad.

Reply on news.ycombinator.com