For those that missed it, Ali Kheyrollahi wrote a post describing his “commentary on the status of .NET” in which he concludes that .NET is a platform for small- to mid-size projects that represent a declining market that will soon die and argues for .NET to pivot. His tweet triggered a very long discussion and at least one blog post in agreement by Rob Ashton, which triggered another long Twitter dialogue. The subsequent discussions center a lot around .NET Core, ASP.NET Core, and all the craziness around the meanings (if any) of beta, RC, RTM, and whether breaking API changes are allowed in each of these various stages. I think it’s safe to say the general feeling outside Redmond is that .NET Core 1.0 RTM is really .NET Core 1.0 alpha 1, and developers are back to waiting for the third release committing to new platforms. (That’s certainly not an absolute.)
The root of this battle, however, appears to stem from bitterness across several boundaries:
- Microsoft vs OSS (which has arguable improved by leaps and bounds)
- Enterprise vs ___? (really just the poorly-named “dark matter” vs not)
- Web vs desktop
- Windows vs cross-platform/Docker
- Azure vs on-prem/other cloud
- C# vs VB/F#/other
- TFS + VS + NuGet vs alternative tool chain
- fill-in-the-blank, e.g. SharePoint vs WordPress
Historically, Microsoft has set the tone, and most of their customers follow suit. Microsoft provided a lot of excellent tools to build applications quickly, and this was seen as a good thing. However, other platforms have stolen the leader role, leaving .NET to copy, borrow, and generally play catch-up. There are a few exceptions, but as can be seen above, most of those are typically given second fiddle and not promoted as well as they should.
I have been quite disappointed over the last year and a half to see how Microsoft managed their transition to OSS. With the exception of F#, a lot of the discussions around the new world of .NET Core have appeared to be a lot less about finding out what customers wanted and instead continuing to tell customers what they want. (This really only applies to a vocal minority and not to the team as a whole.) With the recent announcements about .NET Core 1.0 RTM, that seems to have been rectified to a large degree in that .NET Core will now have a significantly better chance to allow migration from (now) netstandard to netcore. I think this is one of the better moves Microsoft has made in the last few years.
Will this ultimately right the ship and ensure everyone currently using .NET remains aboard? I don’t know. Much like the recent post on JavaScript Fatigue, I think a lot of .NET developers are feeling .NET Fatigue and looking for something else. .NET Core was the future hope, and like it or not, the continuous breaking changes have broken the hopes of many. I gave up on caring at least six months ago. There are enough missing APIs that I can’t move to .NET Core any time soon, if ever.
In the F# community, several are looking for ways to cross-compile to other platforms. Fable compiles F# to JavaScript via Babel, and Dave Thomas did a bit of work to show how one might compile to Elixir. This isn’t restricted to F#, of course. Several projects exist to transform C# to JavaScript, and Xamarin has been transforming .NET code to iOS and Android apps for years.
This leads me to wonder whether the question behind the creation of .NET Core, which I think was something like “Can we make a tiny .NET that can run everywhere?” was the right question. Remember, .NET was created b/c Sun sued Microsoft for extending Java. A lot has changed since then. Java is now supported on Azure! While I think the CLR is arguably better than the JVM, I wonder whether a better solution might not have been to contribute toward the JVM and work toward merging the JVM and CLR. Perhaps Erlang/BEAM is the right target? WebAssembly all the things?
All of these are non-trivial. I’m not convinced any are good ideas. However, what if the right answer is somewhere along the lines of VS Code (or even VS with its Python, TypeScript, etc. tools), an editor for far more than Microsoft-owned platforms and languages.
Is .NET needed anymore?
What if C#, F#, and VB compilers were extended to target additional platforms, e.g. JVM, Erlang, etc? Would you care?
What if you could use TypeScript to build Windows applications rather than C#? Would you care? (For what it’s worth, I would rather write TypeScript than C#, so this is not a made up question.)
What if Visual Studio and VS Code focused on providing excellent tooling for traditionally CLI-driven tools in the JVM ecosystem and integrated seamlessly across the new Linux support coming in Windows 10? Would that impact you?
Is .NET Core a hope for the future, or yet another Silverlight- or Metro-like fad? Can it really succeed where Java failed? (NOTE: Erlang and node.js succeeded in cross-platform support, so it is possible.)
Wizards of Smart 
Please note that I am not saying .NET Core is a complete waste of time. Should the required APIs eventually get implemented, I plan on moving over. I think the .NET Core team has done some really great work. The questions above are to just get the questions out there and get people thinking beyond the easy questions.
LikeLike
.NET is a legacy framework that came out of an era when MS was using these tools to extend Window’s dominance. Non-Windows device support was a secondary thought. We are now in a phase where the overwhelmingly majority of computing devices and browsers are not made by Microsoft so their toolchains are changing and becoming more low level (e.g. Azure, where the current CEO came from) so can support cross-platform. Developers adjust accordingly.
LikeLike
Microsoft didn’t just adopt OSS in the last year, .NET has been cross platform pretty much from day 1. The .NET CLI was ratified as an open standard in 2001 and by the ISO in 2003. From the word go .NET has been a platform available to any operating system. Mono the .NET implementation for Linux was released in 2004. Unity which is built on mono was first released in 2005 and is the leading cross platform game development engine today. There’s very little validity to your statement.
LikeLike
Microsoft didn’t just adopt cross platform support in the last year, .NET has been cross platform pretty much from day 1. The .NET CLI was ratified as an open standard in 2001 and by the ISO in 2003. From the word go .NET has been a platform available to any operating system. Mono the .NET implementation for Linux was released in 2004. Unity which is built on mono was first released in 2005 and is the leading cross platform game development engine today. There’s very little validity to your statement.
LikeLike
Interesting. I’m not sure how well F# would transition to another framework and runtime, though. For example, lack of tail recursion and reified generics on the JVM, plus also the fact that many features in the language were written specifically to interoperate nicely with C# and the .Net framework.
LikeLiked by 1 person
As someone who’s been developing on .NET since it came out I’m happy to say I missed the entire Core debacle. Were the goals of .NET Core ever stated or open for discussion? Hard to argue or feel involved unless we can see what they wanted to achieve and invite the discussion.
Personally though:
Is the wider platform reach a goal? Mono.
Is minimization a goal? Mono has a tool for that.
Is isolation a goal? Docker already does that pretty well.
Seems to me MS would have been better off investing in mono and dev tooling on *nix instead, which is kinda happening anyway.
As it is, it comes of as yet another case of NIH syndrome from MS, just like ORM, MSUnit, package management and so many other things before that…
LikeLike
I’m not sure whether exact goals were ever written down. I think a lot started out of ASP.NET years ago, they made progress, then it grew in scope as other platforms wanted to join in the excitement. NIH probably drove some of the earlier development. IIRC, there was a big push to get a more node-style development flow available for .NET developers. (This is based on my recollection of community discussions, btw, and I’m assuming this was the input fueling the MS team.) A lot has changed, and Azure now supports so many platforms that I’m not sure it’s as critical as it once was to provide the same level of development flow to bring people to Azure, Windows, etc. Thus my question as to whether we really need .NET or whether efforts might be better spent more broadly making software development better.
LikeLike
The problem that I’m seeing is that the small subset of .NET developers who blog and are active on social media are very much the early-adopter crowd, who will have been closely following everything on GitHub for the last two years, and have suffered through multiple changes of direction in that time. They are also the kinds of developers who will explore what is on offer from other platforms, languages, frameworks, etc.
The fact is that the much larger community of .NET developers and Microsoft customers have been saying of .NET Core: “We’ll look at it when it’s ready”, so what they’re getting presented with as a fait accompli is pretty much what they want: a cross-platform, xcopy-installable version of the .NET Framework for web applications, with most of the BCL APIs intact, and the new NetStandard model to replace Portable packages, usable with Xamarin and UWP projects as well as .NET Core. The potential gains from things like migrating to Linux IaaS or VPS servers and not paying the Windows licensing costs, as well as porting to the latest iteration of the various application-level frameworks, are not inconsiderable, as well as the more ephemeral, harder-to-cost benefits of adopting container-based deployment and various other solutions that have, until now, been the domain of stacks like Node.js, Python, Ruby, etc.
All of these “dark matter” developers and their employers have an enormous investment in both code and skills, and a path to more modern practices and more cost-effective development and deployment processes that does not require a ground-up rewrite, a bunch of retraining and, in the case of the JVM at least, a completely new set of development tools.
One final note: at the end of the day, the bulk of the Microsoft development ecosystem comprises teams developing solutions based around SQL Server databases. .NET supports SQL Server in a way that no other platform (as far as I am aware) can offer. .NET Core continues this level of support, so it will be an obvious win for a lot of customers.
LikeLiked by 1 person
Mark, I think you summed up the whole thing decisively well. Thank you for your comment!
LikeLike
«This leads me to wonder whether the question behind the creation of .NET Core, which I think was something like “Can we make a tiny .NET that can run everywhere?” was the right question.»
My impression (as a tech news follower, I have no inside knowledge) was that this was not actually the question. I think the real question that was asked was “How best can we break down the silos of huge branches and forks of .NET and merge to a more modular replacement?”. Subsidiaries to that question were then “Can we open source that?” and “How do we move it out of the Windows lifecycle?” Making a “tiny .NET that can run everywhere” was the goal of the .NET CF and also Silverlight’s goal (it’s the /E in WPF/E, Silverlight’s other more boring name). For .NET Core that seems more a useful side-effect: modularization and a simpler lifecycle means it’s easier for it to feel “tiny” and to “run everywhere”, when really the goal is to be as big as .NET has always been (it’s just a slow process for such a huge refactor; which shouldn’t be that surprising for any that have done huge refactors).
«What if you could use TypeScript to build Windows applications rather than C#?»
You can do that today. (That’s largely where I am these days, for multiple reasons.) On the modern applications side, JS (and thus Typescript) is an equal peer in the Universal Windows Platform. If you want something seeming more “classic Win32”, Electron has you covered (and also macOS and Linux). Cordova covers mobile platforms (including the UWP). ManifoldJS and the work in the Web Application Platform and web app manifests allow you to build server-hosted applications that play nice as “real” device applications. (The Windows Store supports server app manifests natively today; other devices need Cordova wrappers for now.) NodeJS for any server-side or command line needs you might have. Lots of options all around if you are serious about wanting to do Windows application development in Typescript. (It’s funny you mention VS Code here, as VS Code is a Typescript application, running on Electron.)
«Is .NET needed anymore?»
It’s still a good dependable stack. It’s unfortunate that seeing “how the sausage is made” with the this first truly community reviewed, open source release has turned so many stomachs. I’m curious about the alternate world in which a finished .NET Core showed up after years of secrecy in some big conference announcement, per an older Microsoft status quo, if there would be as much hand wringing about the state of .NET. (Maybe?)
«Is .NET Core a hope for the future, or yet another Silverlight- or Metro-like fad?»
I don’t think “Metro” was a fad. It has an actual brand name now (“Universal Windows Platform”) and from my view that platform is doing pretty well and getting better all the time. Some of the grand experiments in UX have been compromised or lost (sadly), but the overall work clearly continues to build a better XAML and HTML based Windows platform across every device.
I do think that .NET Core is “yet another Silverlight” in so much as it seems a direct descendant of Silverlight efforts, in terms of presumably some inherited code and/or teams. But .NET Core is not a browser plugin and won’t suffer the same “death” of Silverlight in that fashion. .NET Core is the continuation of efforts to modularize the .NET Framework and break it out of the “big giant releases with Windows’ big giant releases” box. I foresee that continuing forward, as I’m not sure any of us (as developer/users) are that anxious to see Microsoft return to the old closed source Waterfall, regardless of the current “agile hiccups” as we all adjust to the new status quo.
.NET Core is obviously the future of .NET. I’d like to think it’s a hopeful future: small, agile releases instead of behemoth releases every few years; modular footprint that supports nice things like .NET Native and easier “side by side” .NET frameworks on servers; open development and community engagement. I’m also a realist and know that while full of hope, it’s likely to continue to be a bumpy future. Agile is not a panacea and open development and community engagement means that not only is the good work and the small changes more obvious, but the arguments louder and more public. This is norm in open source development and you take the bad with the good; it’s just interesting how new all of this is to a lot of the .NET community. It should get better, but I think a lot of .NET developers are going to need to learn how to deal with open source and community engagement issues (growing thicker skins or finding good blinders/goggles that can help them not be too overwhelmed by the bazaar in action).
(Note for instance, that NodeJS only just recently fought the hard fork that was IoJS and caused a giant rift that has mostly seems to have healed, but was an example of how open source works. If anything, the people jumping to the JVM from .NET from some of the issues with .NET Core seem to me to be some sorts of “closed source masochists”; Oracle’s stewardship of Java and the JVM may as well be the old way of .NET behemoth releases, with most of the work seemingly happening behind closed doors, when there’s any work at all happening…)
LikeLiked by 1 person
I remember some people having a go at porting F# to the JVM. They were at a Progressive F# meet up a couple of years ago. I am not sure what happened to that though. With a quick google it looks like it didn’t really get any traction. I like the idea though!
LikeLike
That could have been interesting. Don has said in the past that the JVM would not support F# well because of its lack of tail call support and its different generics (as best I recall). However, there are Yeti and Frege on the JVM to offer something similar. I have yet to find anything I like as much as F#, but I’m learning to like more things about more languages.
LikeLike