Those who know their Brief, Incomplete, and Mostly Wrong History of Programming Languages know what happened between the mid ’90s and early ’00s:

1996 - James Gosling invents Java. Java is a relatively verbose, garbage collected, class based, statically typed, single dispatch, object oriented language with single implementation inheritance and multiple interface inheritance. Sun loudly heralds Java’s novelty.

2001 - Anders Hejlsberg invents C#. C# is a relatively verbose, garbage collected, class based, statically typed, single dispatch, object oriented language with single implementation inheritance and multiple interface inheritance. Microsoft loudly heralds C#’s novelty.

Joking aside, in the early ’00s, Microsoft wanted a productive and safe framework for writing Windows applications, which included interfacing with com and ole … things. This framework was named the “.net Framework”3³ Named in association with a now largely forgotten marketing push to be hip and cool and online. If anyone asks, the way to be hip and cool and online is to prefix all names with “.net” in capitals. More seriously, part of the push for the .net Framework grew out of the need to distribute com things over the /net/work. I’m sure there was a beautiful vision there.. They could have written this framework in C, but this would have forced all applications to be written in C, which would be directly contrary to the goal of productivity and safety.

At first, they tried working around the issues with C, but it didn’t take long before they realised that working around the issues with C would be much harder than simply creating an entire new language with a runtime and everything.

So they did. C# was born as a “C with classes and garbage collector”, along with the .net Framework libraries. This is where things get a bit confusing, because for a while, C# and the .net Framework were essentially one product. You compiled C# code with the .net Framework, and then ran it on the .net Framework. It’s all a bit opaque and it only happens on Windows.

What makes this even more confusing is that the .net Framework was intended to be a multi-language environment: Microsoft made it run things like Ada, Cobol, Python, and so on, but this never really took off and I’m not sure how well supported those efforts are right now.

I don’t know why, but Microsoft decided it would be a good idea to get a standards body to sign off on C#. This happened in 2003, and Microsoft did this in a way that’s actually sort of good.

Obviusly, they had to un-opaque C# and the .net Framework. They split these apart into separate components, and created well-defined interfaces between them. In this spirit, there are actually two standards: one for the runtime platform and the other for the language.

In 2015, a Brave New Microsoft™ decided to be more open source. They acquired GitHub, they added a Linux compatibility layer to Windows, and they released the source code to large portions of the .net Framework. The .net Framework does still not run on _nwp_s, mind you, but at least now we can see the code that prevents it from doing so.

More importantly, it allowed for much greater information sharing between the Mono and .net Framework projects. In 2015, Mono started incorporating code from .net Framework, as well as contributing patches back.

At this point, we have two relatively similar projects that accomplish the same thing: compiling C# and running cli code. One project works on Windows, and the other project works on many platforms. It was inevitable that the synergy would take a turn for the incestous, and indeed Microsoft acquired the company behind Mono in 2016.

However, it would be bad strategy on multiple levels to try to wrestle the Mono brand under the Microsoft flag, so one more thing happened in 2016: Microsoft created its own cross-platform implementation of the cli, and called it .net Core. This implements the three parts of the cli standard with the following names:

• Core_fx_ implements the cli Standard Libraries;
• .net Core implements the cli cil; and
• Core_clr_ implements the cli ves.

Aside from this, the .net Core sdk also compiles C# to cil.

You’ll note that this means that Microsoft is now in competition with itself, owning both major cross-platform cli implementations: Mono and .net Core.9⁹ This reeks of Embrace, Extend, Extinguish and makes me rather uneasy. This is an unpopular opinion and I hope the masses are right, but I privately worry we’ll see Microsoft fencing in the .net ecosystem soon enough.

It’s also worth mentioning another natural consequence of this: while .net Core may seem like the more production-ready implementation with greater corporate backing, it is by far the younger implementation and I wouldn’t want to say anything about the amount of corporate backing.

All in all, we now have no less than three implementations of the cli standard:

• .net Framework, the original implementation that spawned the standard, ships with Windows and runs only on Windows, and was closed-source until very recently;
• Mono, the early open-source cross-platform implementation that nowadays share a lot of code with .net Framework and is, to a large degree, compatible with it; and
• .net Core, the young attempt by Microsoft to create an open-source cross-platform implementation under its own brand, while taking liberties that break compatibility with the .net Framework.

About the compatibility between .net Framework and .net Core: it isn’t. Microsoft envisions .net Core as a newer, better version of .net Framework and takes the opportunity to improve massively on old cruft where it couldn’t before for compatibility reasons.10¹⁰ And this is where I get a bit sad, because it as far as I can see, it seems like Mono does not support (nor has any plans to support) .net Core. This means, unless I’m misunderstanding things, I have to choose to either use the improvements in .net Core, or build and run my code using the mature Mono project.

Obviously, this leaves the Mono project in a bit of an uncertain future. It looks like the path ahead for Microsoft is to slowly deprecate both the .net Framework and Mono, and encourage people to use .net Core instead.11¹¹ This is indeed what seems to be in the works for the future release of .net 5, but it’s far enough into the future that I won’t read too much into it.

Now that we’ve sorted out all the various runtimes, it’s time to make a brief mention of the best stuff: the F# language. If you are into this, I strongly recommend reading the history of F# recounted by Don Syme12¹² The Early History of F#, Don Syme, 2017. First draft available online., who has been a part of the journey since the start. Anyway, here are the important bits:

The division known as Microsoft Research was invited to participate in the design of the .net Framework. In a fun clash of controversy, despite being invited to participate, Microsoft Research is wholly and completely separate from the product divisions. They had some opinions that were at the time considered academic and impractical, but were still included in the .net Framework (and, by extension, the cli standard.) These ideas include real support for tail-call optimisation13¹³ Functional languages on the jvm need to bend over backwards to get around the lack of tco on the platform., first-class functions14¹⁴ Not by creating and allocating a new wrapper class, as Java does it., and non-erased generics15¹⁵ Runtime-aware generics are the foundation of many newer C# features as well..

Yet, while F# has been very influential in the design of the .net Framework, the opposite is also true: F# was not intended to be a port of OCaml running on .net Framework – rather, F# was from the beginning envisioned to be a .net_-based functional language, with syntax and semantics inspired by OCaml. This is a subtle but important point of distinction. The hardest thing about interoperation between two languages is generally not the compilation to the common platform, but mapping data structures between the two languages without dropping performance through the floor. With the clear goal of being a _.net language, F# was frequently constrained to doing things however they were done in the .net Framework clr.

Being a product of Microsoft Research, F# has always had a sort of half-open status in terms of culture and community outreach. Initial releases of F# shipped with the source code and there has always been a continuous effort to make F# run on Mono. While it wasn’t until 2010 the F# code was truly released under an established open source licence, this air of open development that has followed F# is the reason it sometimes feels like there’s better support for F# than C# on nwp.16¹⁶ At the time of writing, .net Core does have support for building and running F# projects, but the tooling is – as always – lacking. The best F# experience on _nwp_s are through Mono.

Completely orthogonal to the standards, there’s also Microsoft Visual Studio, which greatly influences how people work with .net code. In particular, Visual Studio stores important information regarding .net projects in project files, generally with a file extension like .csproj, .fsproj, etc., depending on which language the project uses.

It is far from trivial to compile a .net project without the information contained in those project files, which lead Mono to include a tool called xbuild which reads those files and compiles the whole project. These days, Mono shares enough code with the .net Framework to instead ship an msbuild executable for doing the same thing, and thus xbuild is deprecated.

Similarly, multiple Microsoft Visual Studio projects can be linked together (i.e. loaded/built at the same time) by listing them together in a Microsoft Visual Studio solution file. These files are also supported to varying degree by the different implementations of .net.

This text is way too long already, but I have to give this a brief mention as well. There has always been an asp.net framework for creating dynamic websites, shipped with the .net Framework, alongside with the libraries for creating Windows applications.

What has happened in the .net ecosystem, and the industry at large, is a gradual shift from component-based Visual Basic-style gui applications to web applications. In later versions of .net Framework, the main selling points are no longer the gui builder tools, but the asp.net framework. With .net Core, this is taken an additional step further: there are no longer any gui builder tools; it’s all about the web.

And with that, Microsoft has, in some ironic way, gone from 2001 over to 2019, and in a process of slowly correcting mistakes, begun fulfilling the initial goal of being hip and cool and online. They finally have reason to call it .net.

• .NET on Linux: What a Contrast