Hmmm. Aaron is cool, but also works at Shopify. Neither DHH nor Aaron mentioned anyone at the gem.coop project. I can't help but have mixed feelings here.
I think the underlying issue is much bigger than merely contained on speed. It also has to do with control - both for developers as well as users.
This is also why I think the label "prematurely" is weird, because it attempts to singularize everything down to the speed label. I think the issue is much wider than what is faster. In fact, speed doesn't interest me that much; whether it takes 0.35 seconds or 0.45 seconds or even 1.5 seconds to install a gem, is just so irrelevant to me. But, for instance, high quality documentation - now that is an area where ruby failed in epic ways. Not all projects but many. And then ruby wonders why it is dying? And nobody wants to focus on these issues really. So the issue should really be viewed much larger in scope than "merely" "speed is the issue". I mean ... matz focused on speed in the last 10 years. Ok. Ruby declined. Well, perhaps it is time to focus on other things more - not that people mind a faster ruby, but if a language is dying, then you need to think really hard, come up with a plan, multiple ideas, and push these hard. Rather than, say, purge away old developers and claim nothing happened here and all is well ...
I don't know a lot about Ruby, but I'd wager what its missing is a hero app or framework. Ruby on Rails got folks interested for awhile, but I guess other frameworks won out. What left does it have? What domains does it excel at?
Python has ML. JS has web. C/C++ has performance. Rust is stealing a slice of that thanks to safety.
That probably covers like 99% of things, at least from my world view. There are arguably other better languages but it doesn't much matter if the community all flocks to the well established ones.
There is no single established framework/language for backend Web development. There are many options, all valid, differing in popularity based on their qualities (or sometimes just hype).
Ruby used to be cool around 2010, but it lost to better options. Ruby has strange syntax, and Rails abuses magic, so I guess the viability of TypeScript for development made Ruby less popular.
> Ruby used to be cool around 2010, but it lost to better options.
I'd argue that it lost the cool kidz mindshare but not to better options. People jumped to Node.js because of async but in the end the relevant industry change was the switch to SPA based architectures in the web space. Rails never embraced that approach and hence lost the popularity.
Jump 15 years ahead, and now the Enterprise world is built with React and Angular apps, not with JSPs or Spring MVC apps. Can Rails do a comeback? Who knows, but it's still a bona fide web development stack with terrific productivity gains for those who want to optimize that metric.
I think the underlying issue is much bigger than merely contained on speed. It also has to do with control - both for developers as well as users.
This is also why I think the label "prematurely" is weird, because it attempts to singularize everything down to the speed label. I think the issue is much wider than what is faster. In fact, speed doesn't interest me that much; whether it takes 0.35 seconds or 0.45 seconds or even 1.5 seconds to install a gem, is just so irrelevant to me. But, for instance, high quality documentation - now that is an area where ruby failed in epic ways. Not all projects but many. And then ruby wonders why it is dying? And nobody wants to focus on these issues really. So the issue should really be viewed much larger in scope than "merely" "speed is the issue". I mean ... matz focused on speed in the last 10 years. Ok. Ruby declined. Well, perhaps it is time to focus on other things more - not that people mind a faster ruby, but if a language is dying, then you need to think really hard, come up with a plan, multiple ideas, and push these hard. Rather than, say, purge away old developers and claim nothing happened here and all is well ...