The papers are great, a lot of research has been done in this area despite the closed nature of .net prior to the recent open sourcing. Too tough to summarize in one comment but I want to add a few things for anyone thinking of checking them out.
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.
Do you really think the engineering in the JVM is that bad? I can't think of many VMs that have the technical capabilities that HotSpot or Graal do. The CLR doesn't even do basic speculative optimisations. Maybe Azul Zing or J9 are comparable in terms of the advanced techniques they use, but would you really put the Oracle JVM that far behind? I'm not sure there's any sound technical basis for that.
It's more that a lot of the work people admire was done before or close to the acquisition date and therefore probably should be credited to Sun.
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.
Evidence: JRuby, Clojure, Groovy are dynamic languages that have been successful on the JVM and that simply can't have the same performance on the CLR for obvious reasons. Microsoft tried investing in IronPython and IronRuby but failed. Furthermore a language like Scala can have a type-system that diverges from that of Java (e.g. higher kinded types) without taking a hit in performance.
It's not dark magic, it's just good engineering. And the evidence is there in plain sight.
Microsoft didn't fail at IronPython and IronRuby for technical or perf reasons, they owned the projects and essentially withdrew funding, presumably this delayed all the dlr work too dynamic invoke etc.. rosyln changes etc.., it was a disappointement at the time to me 2010? and essentially allowed the JVM to pull ahead in community adoption of other languages. Where MS is now this decision to withdraw from iron* looks insane, but the attitude to open source and community was different then. Time has pasted. Happy clojure developer on JVM today
I'm not sure I believe what you're saying is true. I'm a full time Clojure dev and let me tell you, if I give a damn about performance I avoid a lot of the cool parts of the language.
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.
Ditto with Apache Groovy, which started off as a dynamically typed language to complement Java. The original use case for Groovy was to use it when performance doesn't matter (e.g. scripting, testing, glue code) and Java (or some other statically typed language) when it does.
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).
Hi sorry for off topic question. But how do u feel about clojure ? I am a python developer and really interested in clojure. Do u think it's worthwhile learning ?
Actually the JVM support for dynamic languages (invokedynamic) was only added after .NET, thanks to IronPython project, created the DLR first as a side project, then eventually released it as part of .NET 4.0.
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.
It sounds absolutely fascinating, but it's a little sad that it did not go beyond the research stage. Like building a flying car and then hiding it in a garage. I understand how difficult it would have been for Microsoft to turn Midori into a product, but still I would like to see what that would have been like.
I don't agree. I think it's one of the strength of a large corp like MS. They are able to separate research and prototyping from product development.
You don't turn a research project into a product. You learn from it and incorporate it into your products
I think they could have turned it into a product if they had wanted to.
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.
Well, as I understand it, several of the Midori devs are now working on the Roslyn compiler and/or the CLR. So so of the lessons learnt will make it into the runtime, so at least that's something.
But yeah it would be nice if they could open-source it.
Has anyone done the same thing for the patents? They won't be as readable, but I would assume there are far more disclosed inventions developed by the .NET teams than academic papers (and you'd have to search the USPTO database instead of the .NET sources).
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.