Part of the reason Java hasn't reified generics is because C# did and it was a real big headache that also limited non-C# languages on the C# runtime (CLI?). Everything had to be recompiled to work with newer C# runtimes. While it's pretty easy to run a bunch of language on the JVM (Javascript, python, ruby, clojure) doing the same for C# is somewhat a nightmare, particularly for non-type aware languages.

For example, Imagine you have an api like `void do(List<Foo> foos)`. In the erasure environment of the JVM that looks like `void do(List foos)`. From python it's pretty easy to call with a `foos = [Foo()]`. But not so much if your python implementation needs to figure out how and if it can coarse it's `List` type into a `List<Foo>` type.

▲

kuhsaft 2 hours ago | parent [-]

I don’t think that’s the case. You can absolutely implement a type-erased language on top of the CLR. Your language will just have the same constraints of a type-erased language like Java.

Having reified generics in the CLR just lets you store more type information. There isn’t much of a trade off for CLR end-users.

Compare this to the constraints and workarounds that Kotlin and Scala have due to type-erasure on the JVM.

▲

pregnenolone an hour ago | parent | next [-]

> Compare this to the constraints and workarounds that Kotlin and Scala have due to type-erasure on the JVM.

The creator of Scala disagrees: https://youtu.be/Xn_YpUtXWT4?t=850

▲

cogman10 2 hours ago | parent | prev [-]

You CAN do it, but it's much more difficult.

And as far as I'm aware, both kotlin and Scala don't really suffer due to type erasure.

	▲	kuhsaft 2 hours ago \| parent [-]
		I mean, the language is what it is. But, it definitely constrains the language developers. Especially when considering interop with other JVM languages. That being said, it is easier to write a language on top of the JVM with good interop, since there are less ways to implement features. Essentially, your language has to interop with Java. And it is harder to have good interop between CLR languages because there are more ways to implement features. Essentially, your language has to interop with C#.