I think it’s because it’s getting into the next stage. When it first came out almost all projects using it were new. Now it’s getting to the stage where new people are coming in to maintain existing RoR code bases, and that’s very different. RoR is great for quick development but it can be much more challenging to jump into an existing code base that’s been running for a while and has had a few different developers go through it ;)
We're moving away from a Ruby codebase now. Everytime I have to grep the codebase to find where a method magically came from, I die a little on the inside.
I won't say it is a bad language, but it allows and seems to encourage some bad habits.
I pretty strongly disagree with the idea that Ruby encourages those bad habits. But Rails? Specifically, ActiveSupport? Yeah, totally. But, effectively, Rails is building a context-specific DSL for web apps that happens to be leaking methods into your code. This is much, much more a Rails problem than it is a Ruby one.
My standard web stack is grape, grape-swagger, grape-entity, and Sequel (with some handy libraries like Ougai kicking around) and I don't run into any problems like that.
Rails in particular is the worst about that. Bonus points if you're working on an older codebase that's been upgraded through a couple versions, but is still fairly out of date. I hate having to keep so much fiddly crap in my head when, with a better language and/or framework, my tools could tell me what I need to know when I need to know it. Ugh, dynamically-named automagical variables and methods the definitions of which are ungoogleable and ungreppable. Gross. "Magic" is almost never worth the cost.
A Sinatra project written with some discipline and taste isn't too bad, though, and Ruby's still my preferred language for throw-away one-off tiny scripts, mostly because it's very concise, has lots of available libraries, and isn't Javascript.
I don't think Ruby's a bad language, but unless you've built some very good programming habits, it's really easy to get "too clever" with Ruby metaprogramming and do something that's conceptually neat, but makes everyone else who works with you want to strangle you.
I left Ruby behind last year to program Go full time. It's much easier for me to not have to do the mental gymnastics of figuring out where a Ruby method came from.
How hard do you think a Go app would be for a medium-large sized web app? I wanted to write a payment processing website in Go, but I'm hesitant to start using that language.
> Everytime I have to grep the codebase to find where a method magically came from, I die a little on the inside.
Are you using Rails? My experience is a lot of the "magic" comes from the use of Rails not the language itself. Though since Rails inspired so many other Ruby frameworks and libraries, the magic has spread a little bit.
Overall I like Ruby for writing DSLs since it has tools in the language that make doing so really easy. But for a website I would... and this is going to be really unpopular... actually probably choose PHP over it. Easier to find coders, equally bad coding practices, but less magic.[1]
[1] IRL I tend to choose Node.js or Go but I have used PHP extensively in my career because it is everywhere. And Ruby because for the longest time Ruby was cool and PHP was frowned upon. Now they are both frowned on.
I don't think that is why with Perl. Granted it's been over a decade so opinion might have changed but when I was in college Perl had a reputation as being a "write only" language. Where unless you had comments / documentation to explain it to you, if you encounter code you didn't write (or you wrote 6 months ago) good luck figuring out what it does.
All languages are like that to a certain extent but Perl more than others.
I had a lot of junior folks complaining about "un"readability of my Perl codes back when I used to work in finance. There were a lot of seasoned Java and C++ programmer on the business side who didn't have much problem hacking their way around Perl, but most folks on the operational side had less than a few year of shell, Python, PHP. I ended up rewriting their codes for speed, brevity and correctness -- and it drove them crazy.
But I've also seen a fair share of properly functioning, yet incomprehensible Perl codes so I could see why so many are turned off.
Perl definitely can be "write only", but it doesn't have to be as long as you don't try to be too clever, but I could say the same about most languages. I wouldn't want to work on a stack that was centered around Perl, but it is fantastic for quick one off scripts or relatively simple file processing tasks