I get things done faster and more maintainably (for future me and other devs) when I do it in rails. Hopping into apps that rely on (request, response, next) always hits me with a learning curve every single time I come back to em, which gets worse as complexity rises. It could also be that I'm very bad at thinking in terms of pipes and need to practice that more.
I also find that in rails, there really aren't _that_ many ways to do things. And, in general, apps that age gracefully always figure out how to phrase their domain concepts through the smallest restful url's/resource mappings they need. There's a lot to be learned from the approach the smaller micro frameworks take, and you can get the best of both worlds in a lot of ways.
Rails performance relative to JVM+Scala+Play is tricky to measure but the closest thing to a decent benchmark I know of is this: https://www.techempower.com/benchmarks/#section=data-r16&hw=...
My own experience at ChartMogul with building production services in Ruby, Go and Rust is that the overall throughput of REST API type services increases a disappointing amount.
With JRuby you get to retain all the benefits of the Rails ecosystem. Most of the Go and Scala community is driven by much larger companies who do open source libraries but they don't really build frameworks to help developers build software quickly.
But people that can do it and make it easy for the team to scale are unicorns.
I've yet to meet one that stays on this kind of missions for long because they get a better offer, leaving the custom project to people without the skill to manage it.
And if you think all that is easy, you are not that unicorn because you don't have a perspective going beyong your code files.
I think the increased productivity, beautiful language that rails is pushed everyone in the right direction, I just personally think stopping there is a bad idea, and that while rails is great it's not necessarily the reason it's in widespread use.
I didn't see any mention in the article of comparing install rates for rails versus other platforms (since of course this info is hard to get) -- and there are tons of rails-ish software out there (django being a huge one). If django had been the thing to break through and rails came after I think the roles would simply be reversed.
This was a common complaint about Rails years ago. What are the "magic" parts in current-day Rails that you dislike?
(I disliked the dynamic finder methods, e.g. find_by_city_and_state, which you would now do using arguments to where(). I also disliked the default routing which made every public controller action routable, if I remember right. Those are now either deprecated or removed.)
I haven't even looked at Rails 5 or worked in a recent Rails 4 codebase so I'm sure things are much better but the code I remember the feeling of being perplexed so often at how a worked in previously wasn't my own so I can't go back and remember what parts really made me angry.
Disliking Rails’s built in abstractions seems to come down to only liking abstractions your own devs created which sounds like not invented here syndrome.
I did a cursory google search and found:
https://stackoverflow.com/questions/29697787/rails-call-same...
More generally, my point was that smaller libraries have less space for multiple ways to do things/overlapping concepts. In the codebases I've worked with, I've found myself questioning whether to use one specific rails concept or the other and the resulting "right" choice seemed arbitrary -- like whether I should make a controller mixin or create a helper.
For example, if you look at a framework like sinatra, the smallest/simplest thing you use to respond to a request is just a function. How to use functions properly is pretty clear, there's not much else to debate over.
IMO people are still using rails because a bunch of orgs moved to it from Java years ago, or started with it after some successful hackathon. It's in wide demand because a large number of orgs mindlessly (or mindfully) chose it long ago. Basically all enterprise/large company apps I've seen have been in either Java or Rails. Some places are still using COBOL. Some places are still maintaining/starting codebases in COBOL. I assume that people will be able to make this same argument about NodeJS in ~2-5 years.
Also, the the point about micro-frameworks being bad being made in the comments because you eventually re-implement rails seems to be wrong or badly articulated -- that's exactly the point of using a smaller-yet-composable tool, you don't use any parts until you need them. Sinatra has also leaned into this by allowing pieces of rails to be loaded, and providing a path to transitioning to Rails proper.
I dislike rails because there's too much magic, and too many ways to do things -- it's precisely why I like micro frameworks. Also, the (request, response, next) middleware/handler paradigm is the most composable way to write server software I've ever seen.