Oh, but it does. The type constructor (e.g. List<T>) does end up documented in the bytecode. Both Scala and Java need this because the libraries are distributed as compiled bytecode.

> you can't use advanced Scala generics from Java

I cannot parse that. Of course you can use generified Scala classes and methods from Java. They get interpreted as Java wildcards for the co/contra-variance rules. For site-wide variance rules - Java just interprets those as being invariant. Because Scala does not reify generics, classes and methods defined in Scala are usable from Java - get it?

> I'm sure they could have erased the extra stuff on CIL

Except that it's a pain in the neck to do so. For your own standard library, sure it's not that big of a deal, but if you want to reuse .NET's standard library, good luck erasing those generics.

As a consequence, F# has 2 generics type systems in the same language, one for Hindley-Milner that is type-erased and one for interoperability with C# and OOP. And even so, this is limiting F#, as F# does not do higher kinded types or type-classes and the OOP variance rules are quire limited, but because it has to interoperate with .NET - it's already too complex and I'm not seeing it evolve towards something better (yes, I believe Scala's type system is much better, warts and all).

> Generics in .NET combined with value types are much stronger than Java/Scala generics, there's no boxing/casting of value types.

That's not true. Reified generics isn't the only solution to this problem you know. Scala can specialize the generic types for primitives ... http://www.scala-lang.org/api/2.10.4/index.html#scala.specia...

Apparently baking the generics into the generated bytecode has downsides in flexibility.