The average Ruby dev works at a mid to small sized company, probably a startup, and they are usually contributing to some proprietary SaaS product on top of Rails. Progress is always happening in the Ruby / Rails world but it's really slow.

On the other hand, Python has three popular web frameworks and a huge data tooling ecosystem that just keeps getting better. It's just easier to get things done with Python these days and the gap is so huge that I can understand OP.

k

And a community thrives with many one-persons combining their effort and keep doing so.

I have made many libraries (gems), OpenSource. Some paid, many just for the benefit of this community; your implication that I lament but not put my work and effort up is frankly rather offending.

To continue on this lament: libraries in dynamic languages are rather hard to maintain, due to runtime constraints that progress/change over time. And the one thing I see is a dwindling usage. Less issues filed (good! ;), less downloads, less integrations, less praise, etc etc.

The more I pay attention, the more I see the Ruby community dwindling. I hope this is merely Rails dwindling - I frankly won't mind if Rails is replaced -, but I fear that Ruby = Rails in practicality. And that Ruby is on the way to the COBOL or Perl.

This, I lament, because I think Ruby is, in the niche of dynamic scripting languages, by far the nicest, cleanest and fun to work with. It's tooling and syntax far more consistent and sensible than Pythons. It's concepts far better thought out and much nicer executed than PHPs. And, sorry, everything can be better than JavaScript without much effort.

So, to me it makes no sense to make Ruby the next Python or PHP, because it's already much better, IMO. It's just not used as often. One extra person using it, doesn't change that.

And, it makes even less sense to make Ruby more like Go or Rust, because if I need Rust, I'd pick Rust instead of spending years of my life making Ruby more like Rust (i.e. invest in a type system, some compile stuff etc).

And when I need e.g. WASM runtime (in say serverless functions) or integration of some new fancy SAAS, or LangChain alike tooling, why would I poor months or years of effort into building tooling to compile to WASM, build gems around said SAAS, or help with tools like Transformers for Ruby, when I can pick Go or Rust to compile to wasm today, grab the Typescript package for the SAAS today, or learn, use (and dislike) Langchain in python today as well?

I mentioned a few already. Some more that I recently ran into, are in the niche of "verifiable credentials", SSI and DIID. A weird niche, but relevant to my current work.

There's plenty of work, references, implementations, type-systems for TS, Rust, Python and even .net. But nothing significant (a very few experiments at most) in Ruby.

There's little support for WASM, eventhough that's a promising tech to run and manage backend stuff as well as maybe someday client-side stuff already. There's little tooling to manage cloud infra in Ruby (Chef and Puppet still chugging along, but hardly as omnipresent as Ansible etc)

PHP, Python, Typescript: typing is emerging everywhere, albeit "bolted on". Ruby has efforts in this direction, but far behind the ones mentioned above.

There's no practical "frameworks" or libraries to make games. Very few frameworks or tooling to build desktop software. There's little effort around architectural concepts like Event Sourcing, Hexagonal architecture, Actors and so on. They are there, but I suspect overshadowed by Rails and far less used and documented than their counterparts in other ecosystems.