There is nothing stopping a language implementer from ignoring CLR generics and leveraging erasure to do their own thing. The problem is that such a language is basically cut off from providing a bridge interface to any CLR library that uses generics. I would guess this is why many core Microsoft libraries (say WPF) don't use generics even though they could (but it could just as much be that they were started before generics were pervasive in C#).

The LAMP team actually got pretty far with Scala on the CLR. The reason it didn't go farther was more due to a lack of interesting and funding.

Yup, I mentioned this in a comment below -- interop is always the problem. Then again, anyone who has looked under the hood and seen just how much MS stuff is based on COM knows all about that.

This is so that F# could have higher-order types and interop them with other .NET languages. F#'s type system is simple partly because it strives to use the existing CLR type system, limitations and all.

If you have no such requirements (e.g., Scala, where there's no requirement that Java be able to consume or interpret all of Scala's types), then you can most definitely define a language for the CLR which does this.

F* is not a typo -- that is not F#, it is a separate language.

I am very interested in F*, I heard about it and I'm waiting eagerly for something polished.

Personally I don't like F#, the result, because on one hand you've got the Hindley-Milner type system and on the other hand you've got OOP with .NET generics. It resembles Ocaml in philosophy (I'm sure this wasn't by accident), in that it feels and smells like 2 type-systems in the same language. It's just an opinion of taste of course - but would have anybody used F# if it didn't integrate well with .NET's standard assemblies? So F#'s integration with .NET's generics is very understandable and one reason Scala.NET died was because it was too hard to keep the semantics of Scala, while also integrating well with .NET, which meant the project was interesting only for people wanting to port their Scala code to .NET - for which approaches like IKVM.NET were far better options. I think somebody wrote an interesting paper on Scala and .NET's reified generics, sadly I can't find it right now.

You may have gotten annoyed about hearing this thing about .NET generics not being expressive enough - I also get annoyed hearing about how Java sucks because it doesn't have reification for generics or other such things, when in truth the compiler can handle specialization just fine and both approaches (runtime versus compile-time) have merit and make different compromises.

BTW, I see that you're working on the Roslyn team - you guys are doing great work lately. Keep it up.

Thanks. :)

I happen to agree with you -- I think the technical limitations in both languages/VMs are highly overrated. Java, especially, has been a victim mostly of insufficient leadership and resources, not any fundamental technical issue.

C/F# and the CLR, meanwhile, are probably most limited by backward compatibility.