| I learned Ruby before learning anything about Rails. I've used it off and on professionally for 7 or 8 years for production services, testing, and random glue/batch code. It felt super powerful and refreshing when I was doing C++ daily. And after Perl it seemed like a nice improvement in syntax and readability to me. But... Time has not been kind to my views on Ruby. All that promise turned to ashes in my day to day. All that flexibility and expressiveness led to subjective code reviews and inconsistent styles across files, let alone projects, being worked on by the same team. All that metaprogramming goodness lead to very robust, extendable classes and modules.. that were never extended. They were copy-pasta'd to a new codebase instead because testing the metaprogramming to support both variants was too risky for the project. And once there were two deployed forks no one ever approved time to consolidate them so then the third one was forked... Working with Rails for some internal sites a couple years ago was like my whole Ruby experience in miniature. Started happy and very productive (ahh, generators! I'll just get my boilerplate started.. Rails guides! Actual documentation...) Then it was a little bumpy.. (Ok sure, convention over configuration. But where are the conventions listed? What options are there?).. And then magically working for almost everything. Then I spent three times as much work fixing the last 5% of my issues because they were poorly supported/unusual features, impossible to configure within the default Rails knobs, or basically just growing pains in moving from development to deployment environments. I don't consider Ruby as a hipster language and I formed my opinions of it based on the core language not Rails. Not saying there aren't people who match your description, just offering a different view. I'd summarize it more as Ruby-fatigue. Ruby "in the large" is pretty tedious and working with larger teams has lead to friction (even with good teams trying to be proactive with linting, style guides, code reviews, automation). So I still use it, but it's a "better Perl" for me now. If it's a one file script it's in bash/Perl/Ruby/whatever, if it's a couple files for a utility it's probably in Ruby, but if it's something new and I expect it to be more than that I'll pick something else. |