F# vs C#. Again

Loads of stuff has happened since my last post. I changed jobs. Doing a lot more .NET Core now. Better commute. Still working with really clever people. Anyway – that isn’t the point.

Build 2017 happened. ASP.NET Core 2.0 happened. Apart from pointless Cortana and Azure debugging features inaccessible to professional developers (as you’d need to deploy directly from VS like a cowboy) – the ASP.NET Core 2.0 changes are sound.
With ASP.NET Core 1.x they tried to break apart the framework to deliver only the bits you need. That lead to amazing amounts of boilerplate code in Startup.cs and made it difficult for people to discover which features are available due to the various references you might need to add first. Now you have to install the entire framework on the server – but allegedly .NET will remove unused DLLs when packaging for self-hosting.

This, however, isn’t the point either.

One Twitter flamewar that blew up during build was that you can’t target this preview of ASP.NET Core to run on full fat .NET Framework 4.6.2- which was initially communicated as being On Purpose – move to Core or stay on old ASP.NET. This – of course – alienated a majority of the .NET community whose legacy code and legacy licensing pay for all this innovation were mightily upset and within several hours – a new story emerged stating that the incompatibility is temporary. The core developers, ahem, in the ASP.NET Core team, are unrepentant however.

The next flamewar had to do with F#. This is actually the point. Mark Rendle said he preferred C# to F# which caused outrage and he didn’t back down when all the heavy hitter F# evangelists came out to explain that F# can do anything and isn’t fringe at all.

They are both right, and the problem still is that despite the big words, Microsoft won’t spend the £50 it would cost to have template parity between F# and C#.