[eonwe]

I’d say that it’s backwards compatibility.

My understanding is that moving from 1.1 to 2.0 (that introduced reified generics) required work from developers of libraries.

It was also done in relative infancy of the ecosystem.

But I trust some c# oldtimer to tell me how it actually was as I only remember that some tools I used insisted to have older .net runtime installed.

[Kwpolska]

Value types (structs) were in C# 1.0, and they’re used e.g. in native code interop.

Java generics use erasure, and they are backwards-compatible with non-generic-using code. You can still say `var l = new ArrayList();` in the latest Java versions; you’ll get a compiler warning, but the code will compile and run as well as code using `ArrayList<object>` would. C# uses reified generics (which are faster, saner, and more expressive), and standard collections exist in two namespaces (System.Collections vs System.Collections.Generic). If you needed to work with legacy code that uses the non-generic types, System.Collections.Generic.List<T> implements System.Collections.IList (but the code would need to be smart enough to demand the IList interface instead of the concrete System.Collections.ArrayList implementation).

[kaba0]

> reified generics (which are faster, saner, and more expressive

I wouldn’t go as far to claim that, e.g. it is often claimed to be the reason behind why the JVM has a blooming language ecosystem, while the CLR, not so much.

Generics have language-level semantics and they may decide to do it differently, in which case erasure gives better results.

[miffy900]

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...

[Kwpolska]

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).

[kaba0]

Scala actually was implemented for the CLR, but was later dropped. Here is what its creator said: https://news.ycombinator.com/item?id=14179881

[tadfisher]

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.