"Previously, we have presented one of the two opensource licensed projects related to creating a C# kernel. Now it's the time to complete the set by rightfully presenting SharpOS, an effort to build a GPL version 3 + runtime exception licensed system, around a C# kernel of their own design. It is my pleasure and priviledge to host a set of questions and answers from four active developers of SharpOS, that is William Lahti, Bruce Markham, Mircea - Cristian Racasan and Sander van Rossen in order to get some insight into what they are doing with SharpOS, their goals, their different design and inspiration."

I keep reading about all these experimental OSs build with C# (and other managed languages) and I'm still a little confused about one thing: What makes C# better for building a kernel than C/++ and/or assembly?

The big advantage is software isolated processes.

If your user mode programs use the verifiable subset of the MSIL instruction set, you can let all processes run in the same address space without security problems.

This gives a huge performance increase since interprocess communication can be done by just passing around pointers. A kernel call does no longer involve costly copying of arguments and CPU mode switches.

In the long term, a CPU designed for running an OS using software isolated processes could be simplified tremendously. So you could squeeze many more cores on the same die space.

Don't get me wrong, I'm all for progress and experimentation, I'm just a little puzzled what such a high level language can offer in terms of kernel performance and stability that lower level languages haven't offered for a great deal of time already.

The performance of C# and java actually are quite close to the performance of C++ when done right. Especially for .NET languages that support value types (structs), there is no theoretical reason why C# should be slower than C++. Of course C++ compilers have more mature and more optimized code generation algorithms, but that is slowly changing. For example, the next version of the JVM will get stack allocation, and the next version of the CLR will do much better struct inlining.

Unfortunately, most java and C# programmers do not realize the performance potential of managed languages because they are creating thousands of objects in inner loops. To write high performance code, you need to know how the language constructs are mapped to machine language, and most programmers simply do not know or care about such details.

Is it just a case that these are geeky projects some programmers have taken up "just because they can" (which is as good a reason as any for building experimental systems) or do these projects offer some serious future gain which I'm naively overlooking?

Like I said, better security, much faster IPC and less requirements on the underlying CPU are the major advantages.