5 ms·

Rails has a bright future ahead despite what this article states. Consider for a moment that most projects just need to figure out product-market fit before we

by xutopia 10y ago

Rails has a bright future ahead despite what this article states. Consider for a moment that most projects just need to figure out product-market fit before we know where to throw the money to scale. 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.

askyourmother 10y ago
Sure now it is Rails 5 - enterprise Rails strikes back! Seriously though, I am looking forward to Rails 8 - with the ActionSecurityHolePipeline.
davidw 10y ago
> 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.
- marshray 10y ago
  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.
  - zdrummond 10y ago
    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.
    - davidw 10y ago
      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.
  - 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 xutopia 10y ago

askyourmother 10y ago

Sure now it is Rails 5 - enterprise Rails strikes back! Seriously though, I am looking forward to Rails 8 - with the ActionSecurityHolePipeline.

davidw 10y ago

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

marshray 10y ago
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.
- zdrummond 10y ago
  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.
  - davidw 10y ago
    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.
- 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.