I firmly believe .NET poses a fantastic programming environment for anyone to build systems, applications, the back bone of companies on top of. I think its significantly better than Java and has received much better support form Microsoft than the Java eco system and the JVM has from Oracle.
Functional languages like F# are allowing startups to build systems quickly that can scale from 0 to millions of users and I think this whole eco system, now that its open, is due for a renaissance.
Several of these papers that you are giving as evidence for Microsoft's better investment are actually about research done into the JVM, by Oracle.
I would guess, but can't really prove, that Oracle invests more money into VM research than anyone else in the world.
That said, I'm not sure why things like speculative execution in the JVM context get such play as dark magic when it seems like the JVM and CLR are pretty neck-and-neck in terms of deliverable performance when we get down to the level where we're not affected by larger architectural differences.
There are a lot of different ways to get high performance code from a VM environment. But to hear many people tell it the JVM is the only competent one. I'm just not sure the evidence bears that out.
It's not dark magic, it's just good engineering. And the evidence is there in plain sight.
And it gets even more severe with Scala.
As Ruby should demonstrate, languages succeed because the community wants them. Not because they have specific performance characteristics.
Unfortunately VMware wasted a lot of resources trying to redefine Groovy as a performant language which could replace Java's use case, or even run on Android (believe it or not).
I also think it's wrong to imply IronPython and IronRuby failed for purely performance reasons.
I imagine only those of us that work regularly with both platforms get it right, when each got what, and even then it is easy to lose track.
- SSAPRE: https://github.com/mono/mono/blob/0bcbe39/docs/ssapre.txt#L249
- Dice, thin locks: https://github.com/mono/mono/blob/49c26ad/mono/metadata/monitor.c#L51
- IBS Tree: https://github.com/mono/mono/blob/0bcbe39/mcs/class/referencesource/System.ServiceModel/System/ServiceModel/Dispatcher/QueryIntervalOp.cs#L10
- Huffman tree: https://github.com/mono/mono/blob/0bcbe39/mcs/class/referencesource/System/sys/system/IO/compression/HuffmanTree.cs#L16
- GC survey: https://github.com/mono/mono/blob/0bcbe39/libgc/doc/gcdescr.html#L13
- malloc survey: https://github.com/mono/mono/blob/0bcbe39/mono/utils/dlmalloc.c#L1501
Safe Systems Programming in C# and .NET
It details some of the Midori project lessons learned and how they impact the design of C# 7, .NET Native and future .NET versions.
They had, however, a very, very good reason not to - it probably would not have been backwards compatible with Win32, so the huge amount of third-party software that exists today could not have run on it. And that - whether one likes Windows or not - is a very compelling selling point.
So things they learned building Midori will trickle back into the Windows/.Net world. I agree that that is what a good research department is for.
But still, it would have been nice to take Midori for a test drive and see what it would have been like.
But yeah it would be nice if they could open-source it.
So that is something.