This is awful news for .NET devs- ASP.NET MVC is the best thing that's happened to ASP.NET since it began. Losing the lead guy on that project is worrying.
but, unfortunately Mono just doesn't cut it (Boehm GC? Really? s-gen is a nightmare too, before you counter with that) and Windows isn't a realistic option for a lot of people.
Forget about web stuff though. Mono fastcgi is not production ready (lots of little things, the interplay of nginx and Mono's fastcgi server 'lost' some routes, particularly scriptmethods).
Mod_mono is better... until you start getting OutOfMemoryExceptions. My understanding of the problem is that the Boehm GC is non-compacting, and thus, unless you (somehow) craft your application memory use patterns perfectly, will run out of memory if you churn through enough allocations.
From the mono ASP.NET FAQ:
Why does the memory consumed by the Mono process keep growing?
Mono currently uses a conservative, non-moving, non-compacting garbage collector. This means that the heap is not compacted when memory is released. This means that applications can produce memory allocation patterns that will effectively make the process grow, just like C, C++, Perl, Python applications would.
It is hence important to not get into patterns that would create these holes, for example such a hole could be created if you create a block of size SIZE, release it, and then create two blocks of size SIZE/2+1.
ASP.NET in Mono is particularly vulnerable to this kind of memory problems because it is easy for developers to define APIs that transfer large blobs of data like entire image files, these would allocate a lot of memory that can easily be fragmented.
A simple solution is to try to write your software in a way that large data blocks are not allocated, but instead your application handles them in blocks (like writing a "copy" command).
So the new GC, S-Gen is available, but for us at least, ~6 months ago it was really buggy. Some of our code would inexplicably cause mono crashes in the allocator. We couldn't run our apps with it, at all.
So ultimately we were left with restarting our webserver process every 30 minutes or so, or we could switch back to Windows web servers. Mono was decently performant, but going back to Windows we had a slight but noticable performance increase.
Don't get me wrong, Mono is awesome for a lot of things, and it kicks fuckin' ass to run my C# on Linux. But the ASP.NET side of things is just not mature enough. It's possible I'm just a bad programmer and if I'd taken the time to re-architect our allocation patterns to play nice with Boehm this story would have a happier ending, but alas :)
P.S. None of this stuff is fresh in my mind right now, so shoot me an email you have more questions or run into any specific situations or whatnot.
I would want to deploy ASP.NET MVC3-based web applications so restarting the web server sounds like it'd be my only option (I'm not going to waste my time re-architecting things if it's eventually likely to run out of memory anyway).
Then again, I haven't tackled switching away from MSSQL (aside from learning to use a new DBMS, I'm a fan of stored procs too so I'd have to learn a new SQL dialect), either. Since my time is probably worth more than Windows licenses, it looks like sticking to Windows is the logical choice for now.
Thanks for the offer to pick your brain... I may take you up on it some time :)
FWIW, Postgres does stored procs, too. Different SQL though, of course.
If Microsoft had their heads screwed on straight MVC would be the default ASP.NET web-site project type in Visual Studio and Linq would have gotten the love it deserved, even if it competed with EF. I fear that without Haack's leadership MVC will be mishandled and slowly die off.
Edit: To clarify, I mean Linq to SQL. It was a decent, lightweight, highly usable ORM that has now been more or less deprecated in favor of EF. For now it's not so bad because Linq to SQL only just recently wandered off into the twilight, but eventually the lack of support will make it harder and harder to use and EF will be the only option.
Also, I think it's a natural progression for the project to start out as a "skunkworks" system, and be gradually more mainlined as it matures. It's on version 3 now, and version 4 is right around the corner.
I'd rather see it happen that way than have a huge release and a giant push onto a platform that isn't fully realized. Most "enterprise" organizations would never move onto a version 1.0 platform anyway.
Unless you've got a free ticket onboard the MSFacts Train.
That strategy has certainly fattened their wallets handsomely over the last several decades, but it's ultimately self-defeating. By failing to capture the most skilled developers, and by failing to cater to the most critical development needs (high-throughput business critical web services being a prime example) they have been alienating such developers. And those developers are ultimately the ones who set the standards (in some cases literally, when they are in positions of power at large companies) that other developers tend to follow. And that momentum can be difficult to break. By the time MS realizes it they will be obsolete faster than they can react. And it won't be because the entire world changed overnight, it'll be because the world has been changing for a long long time and it will have finally caught up to their core business.
I didn't realize I was having a discussion on Slashdot. My mistake.
Also, FWIW, a lot of Microsoft's biggest public facing sites run on ASP.NET MVC now, so even if you assumed a lot of stupidity or evilness, there's a lot of inertia behind ASP.NET MVC.