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.
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.
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.
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.
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.
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.)
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.
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.
(To be more specific, I object with how professionally-done Medium posts look, in contrast with their content, which often seem amateurish at best.)
For example, C is a great tool. But heaven help someone if they ignore its' sharp edges.
There is no silver bullet. So the best you can do is find something that suits you, and the task(s) you are trying to accomplish.
If your entire purpose is to ship a product quick, you should be ignoring the "too much magic, too many dependencies" narrative and building something, which Rails is wonderful at.
If I was learning, I'd build an app with the current stable version of 4, a toy crud app with 100% test coverage, then try to convert that to 5. Then compare that to building 5.0 using it's generators. You are likely to work with legacy code, so learning 4 is not bad. May well do that myself, so I'm catching gotchas like the integration test changes in my toy and not at work on a deadline.
But yeah, coding, at least for me, is all about trade offs, and as long as you understand the rails trade offs and mitigations, you are fine.
And honestly when it comes to learning languages ideas are transferable, the only thing that changes is the wrapping around it. Learn what seems interesting and useful, and use the right tool for the right job.
For any given technology which manages to take off at all, there's generally at least a ten year span during which some groups of early adopters are calling it "old and busted" and moving on, while other people are just discovering the "new hotness" and piling in. Just because this guy has switched from one group to the other doesn't mean you need to follow him; if the technology is good and meets your needs then hey, take it on, it'll be great.
The other thing that happens is... well, most of what this article is talking about has nothing to do with technology in the first place; it's more about the community built around that technology, and the fact that the author no longer feels like that community is going in a direction compatible with his needs.
I'm not part of the ruby community at all so maybe he's right and the "roadmap for rails is bleak" - but I'd bet that it's really more that it has developed further but not in a way that suits this author's needs, so he feels disappointed and alienated from the community, and he is observing that he and the rails community are drifting apart and will soon get divorced.
This says nothing whatsoever about the compatibility of the current rails community's direction with your direction, and it makes no useful predictions about the future development of the rails technology and its potential compatibility with your needs. It could be that the same forces driving this author away from rails are the ones which have brought it to your attention as something worth learning about and investing in.
Oh, the irony: https://news.ycombinator.com/item?id=8787117
Frameworks are like hamburgers at maccy ds - consumption for the masses, no thinking required. Later in life those decisions can be a problem.
Getting up and running and building things on a huge foundation like Rails is easy but you should also act responsibly and take the extra steps required to understand what's going under the hood. The effort of understanding a set of well defined "small" libraries is less daunting than a whole monolithic framework (probably with tons of bells and whistles you rarely even use) but both approaches (compare for example the style of the Clojure web app community vs Rails) have their benefits. A set of libs can be adapted more easily to specific needs and development of each of the individual dependencies can move fast without worrying about the others. On the other hand Rails changes relatively slowly but each Rails app being just another Rails app with all the pieces where you expect them to be can be considered a big plus in maintenance.