A couple of things seem off on this perspective, mostly that modern web development has gotten weird, irrespective of Rails.<p>"The ambiguous, english-like syntax of ruby that makes rails so easy, is exactly why it’s not simple."<p>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.<p>"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. "<p>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.<p>"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.<p>"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.<p>"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.<p>"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.<p>"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. (<a href="http://bitworking.org/news/2014/05/zero_framework_manifesto" rel="nofollow">http://bitworking.org/news/2014/05/zero_framework_manifesto</a>)<p>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.