For reasons that aren't fathomable, Microsoft has decided to lift some of the covers from its systems programming language based on C#, which seems to be called M#.

Joe Duffy, one of the team that has been developing a systems programming extension to C# for the past four years, has finally been allowed to talk about it. The first of his series of blog posts reveals little about the language apart from its general philosophy. 

Duffy begins by saying the obvious:

"The first question is, “Why a new language?” I will readily admit that world already has a plethora of them"

but then goes on to justify the new language just like every other language inventor or enthusiast before him. In this case the idea is that C# is a great language but it is marginalized by the law of the "excluded middle" by being fairly easy to use but not very fast.

The argument is that there are languages that are faster, C/C++, and languages that serve in the "easy to use" category, e.g. JavaScript. However, the argument is that you need a safe but fast language for system programming and hence M#, which is based on the managed language C#. In other words, M# is designed to occupy the top right quadrant in the diagram of safety versus performance. Notice that "safe" in this context means something like "memory safe", i.e. data structures don't overrun their allocations and you can't arbitrarily access memory. 

Well who wouldn't want a language that has the best of both worlds. Of course, many C# programmers would argue that it could occupy this quadrant simply by having a better runtime implementation. Others would argue that C++ could be made safer and will always be faster than C# anyway. 

But why base the new language on C#?

"Type-safety is a non-negotiable aspect of our desired language, and C# represents a pretty darn good “modern type-safe C++” canvas on which to begin painting. It is closer to what we want than, say, Java, particularly because of the presence of modern features like lambdas and delegates. There are other candidates early in their lives, too, most notably Rust and D. But hey, my team works at Microsoft, where there is ample C# talent and community just an arm’s length away."

This seems like an honest and valid answer. In addition there is the point of view that:

"The result should be seen more of a set of extensions to C# — with minimal breaking changes — than a completely new language."

So perhaps we are overplaying the "new language" angle. If as a C# programmer I simply use the parts of M# I want to then perhaps it doesn't actually add yet another incompatible language to the Babel.

It is worth noting that the codename M# isn't used in the blog post but the history of the group producing the new language strongly suggests that it is the M# language used in the production of Microsoft's experimental operating system, Midori.   So be prepared to here that it might not be called M# after all or perhaps Microsoft is ready to say more about Midori in the future.

The post goes on to characterize the language in the most general terms which can be summarized as follows (see the blog post for the full version):

1. Lifetime understanding
   It seems that while the langauge is safe it makes use of C++ lifetime management and functional programing to provide deterministic destruction of objects rather than garbage collection. 
   
   
2. Side-effects understanding
   This is the evolution of what was published in OOPSLA 2012, giving elements of C++ const (but again with safety), along with first class immutability and isolation.
   
   
3. Async programming at scale
   The key innovation here is a composable type-system that is agnostic to the execution model, and can map efficiently to either continuation passing or blocking co-routines.
   
   
4. Type-safe systems programming
   It’s commonly claimed that with type-safety comes an inherent loss of performance. It is true that bounds checking is non-negotiable, and that we prefer overflow checking by default. It’s surprising what a good optimizing compiler can do here, versus JIT compiling.
   
   
5.  Modern error model
   Contracts everywhere (preconditions, postconditions, invariants, assertions, etc), fail-fast as the default policy, exceptions for the rare dynamic failure (parsing, I/O, etc), and typed exceptions only when you absolutely need rich exceptions. All integrated into the type system in a 1st class way, so that you get all the proper subtyping behavior necessary to make it safe and sound.
   
   
6.  Modern frameworks
   This is a catch-all bucket that covers things like async LINQ and improved enumerator support etc.

Finally the new language is currently being implemented as part of the Roslyn compiler as a service model that is being rolled out for C# and other managed languages. It seems that we can look forward to something happening in 2014 and eventually to the language being open sourced. 

What is interesting about M# for non system level programmers is that it is the first real sign that Microsoft hasn't completely abandoned the managed code idea. Recently the companies attention has been focused on HTML/JavaScript and C++ development with a side order of "you can do this on C# as well". Perhaps is M# is the language of a future operating system; it might mark a return to the belief that managed code is what most programmers need. 

So watch this space to discover if the new language is called M# or even if it is a language rather than an extension to C#.