Yeah it was a great dream, and to be sure, they do support a fair amount more than C#. The availability of pointers, for instance. It's slightly ironic that the inferior JVM is where all the languages run. But that might just be MS being pigheaded with the license to the CLR up until now. (They had an open source version called Rotor that ran on FreeBSD and Mac OS X, but a very limited license - this was around 2003 IIRC.)
But it's clear that MS does not really care about other languages. The APIs they ship are often C# only, taking advantage of quirks in the C# compiler, even. This document would have been better off written several years before, when reality hadn't set it. And also vice versa. The C# compiler has always needed "duck" typing, but instead of exposing it in any principled way, they simply hack it into the compiler on an as-needed basis.
The runtime hasn't been updated in about a decade, to boot. So, apart from the F# folks valiantly getting generics pushed in for v2, everything's been essentially frozen for over a decade. There may have been some kerfuffle around boxing of null nullable types, but nothing serious. Serious, deep, flaws, line reference types always being allowed to be null, just go unquestioned as part of the C way of thinking.
I feel like this was the same as IE. MS saw a huge threat in Java, and responded excellently. Then, after matching it, they got complacent.
Part of the issue may have been the Longhorn fiasco. Without a strong runtime (apart from whatever managerial issues), they couldn't ship an OS, and I think the managed code people lost too much political capital to really drive a continuing difference. Although, even before that, teams inside MS (like Office), were totally against taking a dependency on .Net.
I wonder if a light, optional, ownership system would have provided the performance necessary to have pulled it off. Then you could do something like play with an array without making heap allocations galore. The GC is great, but even short lived, gen0 garbage has considerable costs. (In practice, I could measure a single allocation's impact on a per packet (network sniffer app) basis.)
The CLR advancing at this point seems highly unlikely. C# and it's nearly isomorphic verbose flavor, VB.NET, have decided that advancement is a compiler thing only. Something like type classes? Simple annotations for ownership to allow some use of the stack? I will always dream.
* LINQ+Generics(It's my understand much of the generics work was done for LINQ, not F#)
* RyuJIT
* New GC Modes
* Re-Jit
* MPGO
* Thread pools and TPL
The CLR is under constant development. I think, if anything, now that you can upgrade your CLR version on a per-project, per-build basis there should be an acceleration of released improvements.
The generics work was done by the people behind the F# team for the CLR overall (for v2), well before LINQ existed. (And F# had generics in the compiler using an erasure system before that.) If those MSR folks had not risen to the occasion, C# prolly would have had to used a lame erasure approach just like Java.
DLR and LINQ don't modify the runtime, nor does the TPL.
So there's been some incremental improvement in GC, some advancements in JIT (perhaps driven by Windows Phone needing more AOT support). And this was stuff that was known for a long time, but MS stubbornly refused to do, just like they did with static linking for C#.
But come on, no real serious advancements since the CLR v2. The IL is still the same. MSR came in and gave them a vastly improved type system, and things have sat there ever since.
Maybe that'll soon change, but seeing as how C#'s been just slowly adding F#'s features and toting their compiler rewrite for years, somehow I'm not really counting on any revolutionary language tech coming out of there.
But it's clear that MS does not really care about other languages. The APIs they ship are often C# only, taking advantage of quirks in the C# compiler, even. This document would have been better off written several years before, when reality hadn't set it. And also vice versa. The C# compiler has always needed "duck" typing, but instead of exposing it in any principled way, they simply hack it into the compiler on an as-needed basis.
The runtime hasn't been updated in about a decade, to boot. So, apart from the F# folks valiantly getting generics pushed in for v2, everything's been essentially frozen for over a decade. There may have been some kerfuffle around boxing of null nullable types, but nothing serious. Serious, deep, flaws, line reference types always being allowed to be null, just go unquestioned as part of the C way of thinking.
I feel like this was the same as IE. MS saw a huge threat in Java, and responded excellently. Then, after matching it, they got complacent.
Part of the issue may have been the Longhorn fiasco. Without a strong runtime (apart from whatever managerial issues), they couldn't ship an OS, and I think the managed code people lost too much political capital to really drive a continuing difference. Although, even before that, teams inside MS (like Office), were totally against taking a dependency on .Net.
I wonder if a light, optional, ownership system would have provided the performance necessary to have pulled it off. Then you could do something like play with an array without making heap allocations galore. The GC is great, but even short lived, gen0 garbage has considerable costs. (In practice, I could measure a single allocation's impact on a per packet (network sniffer app) basis.)
The CLR advancing at this point seems highly unlikely. C# and it's nearly isomorphic verbose flavor, VB.NET, have decided that advancement is a compiler thing only. Something like type classes? Simple annotations for ownership to allow some use of the stack? I will always dream.