Today I accept that Rails is yesterday’s software

A couple of things seem off on this perspective, mostly that modern web development has gotten weird, irrespective of Rails.

"The ambiguous, english-like syntax of ruby that makes rails so easy, is exactly why it’s not simple."

First, I found Rails simple and easy, but it has become more complex over time as it has grown to support a variety of uses. The simplicity is not just because of Ruby, which is a low ceremony language, but rather because of the simple structure of the application, with a clear separation of concerns, very easy to find where a particular code item went.

"The meta-programming and object injection that makes it easy to install 1,000 gems into your project without a single line of configuration, is exactly why it’s hard to debug. "

Dependency oriented development is a real problem, but it is insane to blame that on Ruby. I was working with an enterprise Java team last year that had over 1000 .jars in their build. It doesn't necessarily make it hard to debug, but it does mean you have understand a wide variety of different libraries. People are willing to load a library for the simplest of functions (as the leftpad npm case showed). Again, nothing to do with Rails or Ruby in particular.

"The magic of active record, the crazy levels of duck typing and the expressiveness of ruby, are exactly why it runs poorly even on your development box." This is highly dubious- it's very fast on my dev box. The Ruby interpreter keeps getting better, even taking lessons from V8, and you can compile to JRuby if you think that interpreted runtimes aren't ever going to keep up.

"It’s why you have to build a caching strategy in as a requirement from first line of code." This seems like a good strategy regardless, and caching is nicely handled in Rails.

"Competitors to Rails seemed subject to the same problem — basing themselves on interpreted, slow languages that favoured ‘easy to learn’ over ‘easy to maintain’." As opposed to compiled, fast languages like C++ that are hard to learn and hard to maintain? If anything, duck typing makes maintenance lot easier in some cases, where you can add in new types which support existing behavior, without making changes throughout the dependency tree. Even some 8 year old Rails apps we have are quite maintainable. JavaScript code does have a tendency towards messiness, as there are such a variety of schemes for organizing code, but it keeps getting better.

"I should be spending time writing code, not debugging a haystack of mutable, dependency-wired mess." This is your choice! I think it's nice to have toolsets that give people the ability to assemble things quickly, but no one is forcing you to use a gem to do something.

"Swift, Rust, Go, and the rest of tomorrow’s languages, can you marry modern thinking, build a community with simple as a core design goal, and save web development from itself?" This seems like barking up the wrong tree. The thing making web development complex is largely the complexity of the front end. You can turn your back-end application into a separate API and isolate this problem. At some point, these become browser capabilities, and the polyfill approach has promise. (http://bitworking.org/news/2014/05/zero_framework_manifesto)

In reality none of the stuff mentioned in this article is really a shortcoming of Rails as compared to anything else. The biggest change is the move away from the basic nature of REST-ful, URL driven applications. Single page apps are a lot more like desktop applications. Many applications are looking for web sockets. These changes to the basic structure of what a web application is are much more of a challenge to Rails than the Ruby language itself.

I can't speak for Rails, but at least with Python (primarily Flask) it's not internal DSLs that have caused me problems. I don't think Flask attempts to be a DSL at all, actually. From what little I've seen of Django it isn't trying to be a DSL either (unless I'm misunderstanding that term). It's more when I have 2 or 3 Flask libraries or middleware and they each are documented as if they exist in a vacuum but I want to use them all together and I wish it was easier to see that all 3 have functions that take a Flask Blueprint object, so they're probably all related, or that these functions work with URL objects, etc...

It's a general complaint about Python and the tooling I suppose, not specific to web application frameworks.

The author of the post at no point blames Ruby for Rails' failings... But also I'd contest your argument that they're unrelated. Ruby is what enables the too-clever metaprog that make Rails stack traces so opaque. Also Rails has almost certainly been the single largest drive of Ruby's growth and popularity - observe the significant overlap of core contributors to both projects.

That is the other conclusion I came too. The click bate title of it is enough to cause issues though. There is a consensus on this website though that Rails is good enough for ideas I want to get out there so I will stick with learning it, so far it has been fun.

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.