The way generics are implemented is definitely not the reason why the CLR has a non-existent language ecosystem. The real reason is because .NET Framework for years was a Microsoft/Windows-only thing, and is still perceieved that way despite .NET being cross-platform now; yes Mono existed since 2005, but why would anyone invest time in writing a whole new programming language for a platform that was Windows only until 2016? This, despite the technical facilities that allow for multi-langauge implementations in the CLR. All the langauges that support the CLR are Microsoft developed ones: C#, VB.NET, F#, and C++/CLI, the last one still being Windows-only. Even then VB.NET and C++/CLI exist because Microsft internally needed to support old code for a bunch of already existing projects at Microsoft anyway.

Also generics in the CLR isn't mandatory - you can implement a language without buying into the CLR-way of generics. For instance in C++/CLI, you can mix and match templates with CLR generics, but it's in no way mandatory. You can still write C++/CLI code using C++'s native template system: https://learn.microsoft.com/en-us/cpp/extensions/generics-an...

Which languages that are built on top of the JVM would have significant issues if generics weren’t implemented via erasure? I’m pretty sure Scala would be happier with reified generics. I think the CLR might not be as popular a target because of the Microsoft ties (and the main implementation being Windows-only and closed-source for most of the CLR’s existence).

A short way to describe this: you have to throw away all high-level type information in order to execute code on real machines, so the choice becomes when to throw it away.

CLR languages throw it away in the runtime, JVM languages throw some away in bytecode, and Haskell throws it all away in the compiler.