I'm more and more convinced Rails has caused much of the demise of Ruby. As well as make it big in the first place.
I love Ruby. And with a decade of fulltime Rails development, know and like both Rails and Ruby very well. But 'sharp knives' have caused just too many rails projects to become mudballs over time. This makes teams or companies 'move to language X'. When it really was (their use of) Rails causing the mudballing. Let alone Ruby.
'Performance' is often cited, but I'm certain hardly anyone ever had severe performance issues in practice with Ruby. Maybe with Rails, probably activerecord and quite likely their own implementation thereof. But hardly Ruby the Language
1. Start writing software -greenfield-. "Wow this framework is really neat".
2. Grow it over years. Maintain it. "This language/framework/architecture really sucks"
3. We should rewrite it in Rust. Goto 1.
The real problem is that architecture is hard. Maintainance is difficult, scope creap a thing and accumulating technical debt will kill you eventually.
In Rails, getting a Proof of Concept "blog" out there, is done in hours. But all the "shortcuts" like "throw in Devise for auth" will get back to you in future, turning "hours of rapid development" into "months of stagnation". Getting a basis that will survive pivots, quick market changes, scope creep and allow to tackle technical debt when time is right, takes years of experience with not just Rails, but with "software architecture" in general.
Yes, no argument there. Growing projects is plain hard, no matter what language/framework you use. People talk so much about stack choices as if that's where the problem/solution lies. It's more about building effective teams, respecting seniority, not churning out your employees, having good product people (e.g knowing what to build). That's way more important to most businesses than the endless chat about graphql/react/rails/node/php.
But as techies, we tend to view every problem as a technical problem that can be solved by throwing more graphql at it...
Off topic, but how do you evaluate whether you should switch stacks? I have lots of Ruby experience and am not that young anymore. The "easy" thing for me to do is sticking to Ruby, but I'm sometimes anxious about the availability of jobs 10-15 years from now.
> It pretty much did, but then Rails and Ruby's hype cycle faded a bit
It was Rails' hype cycle that turned me off using Ruby & Rails in the first place. It had more in common with the cult I grew up with than I wanted to be part of, and made it hard for a sceptical outsider to get in.
Which is a shame as I think I'd have enjoyed it very much.
I couldn't stand DHH's "I'm right" attitude about everything. I listened about programming and then he started talking about things I know lots about and I realised he wasn't exactly wrong, just hadn't seen other ways of doing things.
You left out Python 3. That lack of a clear transition from Python 2 didn’t help. Despite that, I still think it’s great, but it made it multiple times more difficult for a newbie to get setup.
I've not done Python outside playing around really early on in my career during an internship, but I've never felt attracted to it; the 2 vs 3 debacle, installing the odd tool is like "what" (yeah just do `pip install this`, but first you need to install pip by using `easy_install`), and I've heard dependency management and environment setup is still quite backwards.
It needs a big ecosystem and tooling overhaul for me to be interested.
ATM I'm doing Go, which seems to have gotten the tooling part right at least.
Smalltalk did not have the ?/! delineation that GP is specifically talking about. Not that Ruby used it consistently (it was largely just for enumerators e.g. Array#push rather than Array#push!).