You're making a mistake that many people make: treating the language and the ecosystem as two (almost) orthogonal things.
But in reality the language has severe impact on how the ecosystem can and will develop.
For instance, when looking at statically typed languages, it makes a huge difference if they offer a solution to the expression problem. That allows two author's to write two completely separate libraries (e.g. a library for an http server and a library for json-(de)serialization) which don't know anything about each other and then allows a third author to write another completely separate library that connects the other two libraries together, so that the http library can use the other library for json.
The end user then just has to important all three libraries and has compile time guarantees that it works.
If the language does not support that, then people will find workarounds. But it is still heavily impacting the ecosystem.
> But in reality the language as severe impact on how the ecosystem can and will develop.
This so much.
One, often omitted, property is also simplicity of the language. If the language is straightforward, then there's a much larger audience who can be potential contributors.
Being opinionated in code style is also if value, as it's easy to contribute to others' libraries.
It's one of the reasons I think why Go did quite well as far as quick library ecosystem creation goes. It's fairly simple, at least as far as the basics go, and diving into/contributing to third party libraries is very easy, due to opinionated tools like gofmt and the overall language simplicity.
Whenever I need something in a library that's not supported yet, I'm able to achieve it in less than a few hours, by quickly diving in and making the changes, even in an unknown codebase. The magic is that this works for the vast majority of libraries.
> One, often omitted, property is also simplicity of the language. If the language is straightforward, then there's a much larger audience who can be potential contributors.
With regards to "simplicity" people often seem to confuse syntax vs semantics. They mistake complex semantics for complex syntax. For example people say that Rust has complex syntax, but actually what's happening is that Rust is trying to represent very complex semantics which necessarily results in a complex syntax. This allows more choice for the developer in how things are implemented without extra cost. On the opposite end is python with very simple semantics but is highly opinionated on how things work underneath and thus is inherently incredibly slow for most any serious computation.
I really enjoy Nim for this. It’s also really easy to dive into most any library quickly.
Especially for implementations of cool algorithms where sometimes the only other implementation is a C++ version. There’s a cool sub-ecosystem of people who fiddle with algorithms in Nim. They’re often not even in the package manager, just someone who implemented some paper or whatnot.
There is not much point in “being simple”, as essential complexity has to live somewhere. I much prefer that living in some compiler-enforced construct than in hand-written conventions. Go is terrible because it doesn’t let you use the former way at all.
What I've seen with the current generation of languages with a lot of compiler-enforced guarantees is that they introduce a lot of needless complexity to the vast majority of problems, which are very often simple.
Overdoing monadic constructs is probably the biggest offender here, but Rust (even though I like the design overall) lifetime checking will usually also cost you way more time getting right than just using a GC (if you don't need complicated concurrency).
Main point being, it's not that easy to contribute to libraries written in these.
I believe that it is a different axis - GC solves the whole concept on a different level (runtime), but where they choose to not take those tradeoffs that complexity has to live somewhere.
Monadic constructs are just a convention though, I think it is different.
But in reality the language has severe impact on how the ecosystem can and will develop.
For instance, when looking at statically typed languages, it makes a huge difference if they offer a solution to the expression problem. That allows two author's to write two completely separate libraries (e.g. a library for an http server and a library for json-(de)serialization) which don't know anything about each other and then allows a third author to write another completely separate library that connects the other two libraries together, so that the http library can use the other library for json.
The end user then just has to important all three libraries and has compile time guarantees that it works.
If the language does not support that, then people will find workarounds. But it is still heavily impacting the ecosystem.