I get it, tight coupling and forced architecture aren't ideal. I accept those limitations so I can get Rails' productivity superpowers. I don't just accept them, I embrace them, I've learned the wonderful joy of having everything you coded 6 months ago just slide right back into your mind because it didn't try to buck the convention. I spent extra time understanding that convention and why it exists when I wrote that code, I think most Rails devs don't do that, and so overcomplicate their applications.
I've been on the other side of that tradeoff, so I can see where you're coming from. There's a lot of appeal in making and using your own abstractions that fit the domain better. But the web is a complicated domain in its own right. The right approach is to use one DSL for the web, and make your own for your domain. DHH was right, Rails is your application. To do otherwise is to over-complicate your architecture.
> locked into a dated approach to the domain.
Ugh, seriously? Is this fashion or engineering?
The abstractions Rails uses are fine for a relatively small app (up to 10 models). Beyond that is where the complexity mushrooms and the framework starts dragging down the project.
Solnik's points about create() are very subtle. Think about coercion, validation, and all the potentially invalid or confusing states an app can end up in.
The approach Rails takes with ActiveRecord is fine for a small project, and often benefits consultants who leverage the boilerplate to show superb progress after one month of development, but it fails in the real world.
To be fair to Rails, most approaches to input validation and the creation of multiple levels of nested objects are implemented poorly. Solnik's point is just that Rails serves up a lot of these flawed approaches into one toolkit, and so the resulting ecosystem is plagued by the sum of all the flaws, and the core team is not really seeing the big picture about how to improve the overall state of the ecosystem (why would they, they are getting paid a lot from the Rails status quo).
DataMapper was superior to ActiveRecord. When Merb got merged into Rails, I was certian DM would be the ORM of choice for new projects, but when it wasn't I personally stopped using Rails on new projects. Sinatra + DataMapper is such a superior approach to full-boat Rails too, fwiw. How many thousands of developer hours are spent upgrading to the latest Rails every couple of years for no benefit. How many useful gems are nearly obsoleted, etc.
Rails has had the worst kind of cargo cult success. Most of the gems are weekend projects that lead to a blog post and a bunch of speaking engagements for the writer, and then get left to wither after the community has naively embraced them. This is not the case for all, but it happens way too often.
There are also many, many subtle bugs that are introduced by ActiveSupport. I've personally wasted at least two weeks of time dealing with them over the past 5 years.
Ruby is a great language, but I'm glad someone as talented as Solnik is branching out.
I've worked on several rails applications with a lot more models than that. Some with over 100 models. ActiveRecord has flaws, but I never felt it was a great impediment to getting things done.
A bigger issue (as you mentioned) is the large number of gems that are abandoned or sporadically maintained. I don't see that as a rails specific issue, but it seems to rear its head most often with gems that interact with rails.
Very experienced developers can create a usable codebase in Rails with over 100 models, but it is highly unlikely to happen if someone in Rails' target audience uses it.
Once you grok pattern matching you'll never want to see another Ruby case statement again. Once you compose a pipeline of functions you'll find Ruby Procs a pale shadow of true functions. There's really no such thing as functional Ruby.
You'll end up with more maintainable code, a lower LoC count, easier testing, more mature libraries, and that's just the tip of the iceberg.
Un uncached Play Framework app will probably outperform a highly tuned Rails app out of the box, even with hundreds of person-hours spent in tuning the Ruby app.
Which leaves you more time to work on actual features.
And then you have Akka. Which is a whole other paradigm to master (but with it's own rewards).
And then you have deployment. Which is a huge breath of fresh air.
Sure, you'll miss some few things in Rails. Like Inflection. Add a dependency for one of the ported versions (like: https://github.com/backchatio/scala-inflector. It's just a single file).
The learning curve isn't the smoothest (though API docs for Java/Scala libs in general and the Play Framework guide is far more complete than anything I ever experienced in Ruby-land). But the rewards.
Come to the dark side. :-)
Then I'd have to learn Scala. I do not want to have to learn an entirely new stack. It took years for me to learn Ruby's eccentricities. Sure it would take me less time to learn Scala, but I already know Ruby. You seem like quite the masochist, spending years in one ecosystem trying to build something, then burning it all to the ground and starting all over. Just looks like so. much. effort.
> you'll never want to see another Ruby case statement again
I never write case statements in Ruby. What I do when I find myself needing a case statement is to go looking for the missing class. I'm missing a domain element and OO programming to me is all about clarifying a domain.
> Once you compose a pipeline of functions you'll find Ruby Procs a pale shadow of true functions.
I pipeline all the time in Ruby. A lot of times I'll wrap a data pipeline in a class so I can encapsulate the logic and manage it better. When you wrap a pipeline in a class, you can do things like add immutability to the instance variables. Sure, it's not true functional, but I don't want true functional.
> You'll end up with more maintainable code, a lower LoC count, easier testing, more mature libraries, and that's just the tip of the iceberg.
Let's take these in turn.
> more maintainable code
I love maintaining my code. I fail to see how learning a new stack could actually improve on this for me.
> lower LoC count
Mostly aids in maintainability. Again not at the top of the list of things to improve.
> easier testing
I've changed my approach to testing over the years. Again, this is not anywhere close to the top of the priority list.
> More mature libraries
Again, this is something I've fixed by changing my approach to the problem. Whenever I introduce a gem, I put an interfacing class between the rest of the app and the gem. That way it's easy to swap out if it becomes a problem.
> And then you have deployment.
Deployment sucks in Ruby, not gonna lie. But again, problems are indicators of overcomplication and I've tuned my workflow to drive more simplicity over time. I know Capistrano very well, seeing it evolve over time has given me a keen eye for how to keep it manageable.
On the whole, I like the idea of functional programming and am not opposed to coding in a functional style once in awhile. HtDP changed the way I thought about programming, though I eventually switched back over to OOP. I strongly disagree that there's any kind of magic to functional. Everything in programming involves tradeoffs, and OOP better fits my mind than functional does. I look at pure functional as math-heavy and harder to grok. I want stateful objects, because humans think in terms of objects and not data pipelines.
> The learning curve isn't the smoothest
That one issue outweighs all the purported benefits of all the others. I would much rather spend my time thinking about domains than learning new tricks.
If you like what you're doing, more power to you. I picked up Ruby because I thought it showed promise as a good scripting language and web development tool (this was pre-Rails) at a time c# didn't really excel at either.
> You seem like quite the masochist
Maybe. DM was created to solve a problem. I didn't burn anything down. I just walked away. The best time to do the right thing is yesterday. The next best time is now.
After 8+ years, I realized I'd spent much of it trying to work around limitations in Ruby. It was just time to open myself up to the idea that there is more to programming than what I knew.
The writing has been on the wall for Rails for a while now, we're just seeing an increasingly large number of people publicly moving on from it.
> It seems incredibly odd to leave Rails over this. For what, Java? Unbelievable.
Back when Java was introduced, it was partly taken up because the features it introduced made developers more productive - hardware agnostic code, network programming out of the box...
Nowadays a lot of developers have moved on from Java. Maybe the same thing will happen to Rails...
And as for leaving for what, the author identified both the other Ruby-based stacks and the noon-Ruby languages and frameworks that he sees as valuable. And, no, Java is not on the list.
Your rant looks like a reflexive defense of Rails from someone who hasn't read the source article more than superficially; the article doesn't dismiss the web as a serious domain, it just sees Rails as locked into a dated approach to the domain.