[0] One former dev on one of the Iron* languages posted on reddit about how the CLR failed on its cross language ambitions. I can't find the post, but they gradually found it was mostly C# centric anyways, and ports of other languages were mostly incompatible and second-class
[1] http://whiteknight.github.io/2015/01/15/parrottheend.html
[2] http://ironpython.net/announcements/ for what it's worth...
We provided a lot of feedback, but it's tough for a group of a couple of students (or in the case of Perl, one commercial dev) to keep up with the then massive-breaking-changes drops we'd get from DevDiv every 3 months or so and provide feedback when it was on stuff that was, to the developers, around 6 months old. Often, by the time feedback landed, it was "too late" to incorporate because of product cycles and got postponed. Or the stuff we'd request was a dupe of "add tail call instruction" which had been postponed long before any of us got started in Project 7.
I say this as somebody who then graduated and then went to work in DevDiv for the next 7 years, where I was treated very well, so I certainly have no axes to grind on that front :-)
One example is Rack applications are hosted by Java web containers Just Fine via a server -> Rack mapping. We use this in production for both a Sinatra app and a Rails app.
[0] http://stackoverflow.com/questions/2752979/using-jruby-jytho...
The communities aren't to blame, but Microsoft. Like you said, the past lack of OSS spirit.
But maybe things are changing now :)
Clojure has never, ever been about equality between diffrent versions, the were always meant to be simular but diffrent when the platform is diffrent.
With that said, I'd like a better lib story between Clj and Cljs.
What do you base this on? I have not heared major complaints, I clearly remember Rich saying that it was not technical early on.
> With that said, I'd like a better lib story between Clj and Cljs.
They are working on feature expression, that should help.
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.
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.