Everyone on Roslyn is really excited about this and we hope that it serves as a signal that big things are happening in .NET to make the entire platform more open and agile!
Heh, before joining the C# compiler team I actually hacked on a stripped down Linux kernel and VMM targeted at high performance computing, contributed to ffmpeg and QEMU, ran Arch Linux with xmonad as my main machine, and did my Masters' thesis on Racket in Git, so I'm pretty used to open source.
This is basically old hat for me -- I'm just glad Microsoft agrees it's the way to go. :)
What's the likelihood the .NET VM is open sourced as well? I use Mono right now to run my apps on Linux but it would be great to use the official implementation since Mono has subtle differences.
That's the main thing I would be interested in also, but I'm thinking that's one thing that we WILL NOT see. That could seriously undercut the need to buy Windows servers.
"Devices & services"
Azure is your servers and the .net + C# tooling story from dev to deploy makes the question of selling Windows servers in a VM world moot. Many of the moves coming out of this Build seem to point to a world where it's going to be cheaper and easier to pay for all the MS services and tooling than to try to cobble it together with other people and platforms.
We're looking at a lowered on-ramp to .net apps that run more smoothly than java+linux+every-support-tool-bit (dev-wise) across devices (and things). It's compelling.
Everything from dev to deployment and ops is getting touched at this conf. This shows where MS's strengths can present differentiation. Their profit source is, and has been, building/selling tools and platforms for others to run businesses. When the thing people hate becomes more like what they aspire to have/be, the tension is palpable.
Google is about the only other player nearly capable. But Google's mission has far less to do with selling shovels vs. harvesting and monetizing.
Apple is just not in this space. If anything, they sure feel like a device-only company in this conversation. WWDC is about the garden. Build is handing out spades, shovels, and, now, dirt.
Xamarin's Evolve, last year, felt a bit like all this does. The are big things happening. If nothing else, at least it feels like change, if not progress for devs and consumers.
There's a trade off though. If C# only runs on Windows then a lot of developers who run Linux will never consider C# as an option. If it does run on Linux, then those developers might end up purchasing Visual Studio in order to develop C#. A lot of developers who previously used C# are also leaving the tech for others like Ruby since they aren't tied to Windows.
Yeah. Historically at least, the Mono runtime was one of the weak points when running C# code on Linux and I expect it drove a fair few Windows sales - you could develop applications under Linux but if you wanted them to run well you needed to pay out for Windows licenses. (I believe it's improved a fair amount over the years but is still behind.)
The .NET VM would be pretty much useless on other platforms. It is tied to Windows and it would be pretty hard to rewrite. But standard libraries would be different story.
The garbage collector for example would be very interesting to peruse. Sure threading and synchronization code would be differ but these have been emulated on Linux before to good effect, I don't see any serious barriers there.
Microsoft has released the source for a .Net VM (CLR) in the past:
http://en.wikipedia.org/wiki/Shared_Source_Common_Language_I...
It supported FreeBSD and MacOS X. This suggests it would not be impossible for them to make a multiplatform .NET in the future.
Even if they were to do that, I doubt that it's portable cross platform code. Someone will need to port it, and it's hard to know how the effort required compares with the effort required to optimize the Mono runtime to be as good as the MS one running on Windows...
as someone who doesn't know a whole lot about the .net ecosystem - does this open the possibility for writing server side c#.net web applications that run on linux, with full parity with the windows environment? with or without mono?
The C# compiler is written in C#, so you can use it anywhere with a .NET runtime. Microsoft doesn't ship a .NET runtime for Linux, so you'll have to use Mono, but if your app is compatible with Mono, you're good to go!
TLDR: You can't write the first compiler for a language in the language. However, you can write the second compiler in the language and use the first compiler to compile it.
If you already have a compiler in the language you're compiling, you can update the compiler with new features by the following process, called "bootstrapping". This process is used in gcc for example:
1. Use the old binary version to compile the new source version.
2. Use the binary produced in step 1 to compile the new source version.
3. Use the binary provided in step 2 to compile the new source version.
The results of stages 2 and 3 should be the same (assuming the old and new compilers assign the same semantics to the compiler source code and don't have non-determinism, e.g. using wall-clock time to determine when to stop searching for optimizations).
The bootstrap process can't be used on the first compiler for a brand-new language, because there is no "old compiler" that can be used in stage 1. The only way around this is to write the first compiler in a different language that already exists.
Of course, if a self-hosted compiler is your goal, you can afford letting the very first compiler (the one written in another language) be limited, "dirty," or "hacky". You don't have to implement the entire language in the first compiler; the first compiler just has to support enough of the new language to allow you to write the second compiler.
Anyway, once you have the first compiler, you write the first version of the second compiler in whatever subset of the language the first compiler supports. Once the first compiler builds the first version of the second compiler, the first compiler is no longer needed; you can add all new features to the second compiler only.
New versions of the second compiler (perhaps supporting more language features) can now be produced by bootstrapping. Of course, you can also use the second compiler to compile a totally different compiler implementation written in the new language (this would be the third compiler for the new language).
First you solve the chicken and egg problem by writing a bootstrap compiler for the language in some other language (e.g. a C# compiler in C or C++, or a C compiler in assembly language). Then you can compile programs in the new language, and compilers are programs, so you can write a C# compiler in C# and the binary so produced will be able to compile its own source.
Most compilers I know of start with an implementation in another language and eventually write a self-hosted one. Microsoft already had compilers for .NET, though, so you just compile it with those until it's self-hosting.
Funny you should mention that! There was a really cool article about bootstrapping a compiler nearly from scratch just the other day[1]. But yeah, most people just start with C or C++ until they can compile enough of the language to write a compiler in it.
Some other interesting contemporary examples:
I think as we speak Go is working on its plan to switch from using a compiler written in Go[2].
Rust[3] has kind of a hybrid approach where the front-end of the compiler is written in rust, but generates llvm bytecode which is then compiled the rest of the way by llvm itself. It takes three "stages" for them to do a full compile, first a binary "snapshot" compiler is downloaded and used to compile the compiler (stage 0), then that generated compiler is used to compile the compiler again (stage 1), and then that generated compiler is used to compile the compiler again (stage 2). Stage 2 is actually just a test - its output should be identical to that of stage 1, and if it isn't, something went wrong.
There is a classic lecture from Ken Thompson[4] that I think is really illuminating on how this stuff works, if you're unfamiliar with it.
Could you ask around the office and find out some of the details about the C# bootstrap process? I would be fascinated to know what language the non-C# compiler was written in and also how long they used/improved the non-C# compiler until they switched to the C# compiler.
Oh, the old compiler is just the currently shipping compiler (i.e., the one in a clean install of VS 2013). We've been using and maintaining it since the beginning. It's written in C++, so we refer to it as the "native compiler."
We only stopped bootstrapping using the native compiler about, oh, 6 months ago, since that was when we decided to take a dependency on new language features. The next VS will be the first VS where Roslyn is the default C# compiler.
I assume you mean the Mono C# compiler (the one that the Mono team develops).
Interestingly, no -- but neither can the native C# compiler (that's what we call the old C# compiler that everyone's using in VS right now)!
Why? The C# compiler is bootstrapped, so we actually compile the compiler with the compiler. It just so happens that a while ago we felt we needed a feature so badly for the C# compiler that we introduced it into the C# language (exception filters) and started using it in the compiler immediately. So in order to compile the compiler, you need a C# compiler that supports exception filters, which right now is just the Roslyn C# compiler. Honestly, the feature (and some other small changes we've made) aren't that complicated, so they could be backported to other compilers, but I don't know why you would want to do that.
A few years ago I was on a small team working on a .NET compiler and runtime -- it compiled MSIL into native code targeting x86 and PowerPC. I remember when working on the part of the compiler that built the exception handling routines running into exception filters and wondering what they were for. We were largely targeting C# as a development environment at the time but ended up implementing them in case anyone wanted to use VB.NET. Funny to see that they're now making their way back into C#, even if it's just in the compiler :)
In certain cases, especially with async, using "throw;" can cause a loss of information in a dump. We want compiler bugs to fail fast -- to immediately crash the compiler for debugging and analysis. By using exception filters we can immediately crash the compiler in erroneous conditions, preserving stack, locals, etc.
This isn't just useful for the compiler, but we felt it was necessary for us to make the most reliable, agile product.
I'm not sure any of this would have happened without Miguel. Mono really gave .NET a second life when MS dropped the ball.
It's also somehow satisfying to witness Xamarin's success and further opening of .NET after all the bashing and hating Mono received from the free software community.
P.S. We're the Visual Basic compiler too :)