4 ms·

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 ha

by adamors 10y ago

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.

shimon 10y ago
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.
- adamors 10y ago
  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.
- marshray 10y ago
  > 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.)
  - pmontra 10y ago
    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.

by adamors 10y ago

shimon 10y ago

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.

adamors 10y ago
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.
marshray 10y ago
> 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.)
- pmontra 10y ago
  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.