As a Rails developer for over 10 years now, I definitely agree that going off the rails (see what I did there?) is nearly always painful. Especially if Rails doesn't totally click for you. I can see why that would drive a lot of people totally nuts.
I think that if Rails really clicks for you then it's possible find a way to solve those problems within the same sort of way of thinking that Rails is coming from. But not everyone works the same way, and that's ok!
> Also as far as the natural-language-like syntax, I find that Swift offers a similar benefit, with the added benefit of strong compile-time checks.
Life is short, if at all possible write code in whatever language makes you happy. If that's Swift for you, well then cheers!
I think this is the first part of the insight needed.
The second part, which by far the most productive full stack web dev I know has got completely nailed, is that mostly the right answer to that is to push back on the business/requirements with a good alternative to what they _think_ they want that _is_ in "the blessed path".
A good Ruby dev who has the ability/skill/respect to do that is maybe the closest thing I've ever seen to the mythical "10x engineer" on a consistently repeatable basis...
And this goes for other things besides RoR too, I've got a Python/Django guy who can build amazing stuff in weeks, but he'll tell me why I am not getting what I asked for but this other thing that does the same job (sometimes better) because "that's the right way to do it with Django".
I suspect it is an issue of preference. I am sure it is possible to be productive using Rails, but the interface style and overall structure is a bit heavy handed for my taste. I prefer tools which stay out of my way and I'm not terribly fond of working inside an "ecosystem".
The issue I always had with Rails is that there would come a point where I would want to achieve something which wasn't really in the "blessed path" of a Rails application, and then I would end up with something that felt like a hack to circumvent Rails' default behavior. That, or I would want to do something which is very simple conceptually, but I would have to add some unnecessary complexity and/or ceremony around it to fit into Rails' interfaces.
Also I'm not a huge fan of the Rails' model of having everything from request handling to routing to DB access in one big framework. The needs of each application can be quite varied, and I'd rather plug whatever components together I want to for a given project than to be limited by some outer structure.
> Ruby statements look more like natural language statements than those in other languages
The more I program, the more appreciative I am of a strict compiler. What I've always found with interpreted languages is, while they seem convenient at first, projects inevitably start to slow down under the accumulated "squishiness" due to lack of strictness. I find it's pretty easy to get used to syntax, but there can be a lot of hidden "gotchas" in interpreted code which tend to outweigh any benefits.
Also as far as the natural-language-like syntax, I find that Swift offers a similar benefit, with the added benefit of strong compile-time checks.