After giving the article a few reads it seems that the points are a bit cherry-picked... > Myth 1: .NET is for Windows It depends what you mean by .NET, doesn

After giving the article a few reads it seems that the points are a bit cherry-picked... > Myth 1: .NET is for Windows It depends what you mean by .NET, doesn't it? In-ecosystem a .NET-enjoyer might be thinking about .NET Core, and thinking about building a nice new web API service. But besides that specific case, it still is all just Windows. And I'm not talking about API and ABI dependencies or hard-coded win32 assumptions, I'm talking about making a first-party GUI Desktop application or an application that works together with the OS, natively. And no, until MS dogfoods MAUI in production for a few years, that isn't the silver lining it seems to be (just like SwiftUI doesn't help at all if you're trying to escape NIBs and XIBs - same problems, different flavour). None of this should come as a surprise, Microsoft does after all still make a separation between 'free' stuff with C# and 'making money' with C#, where the latter is designed as a funnel towards buying something from Microsoft and making sure that it works with Microsoft's stuff (which is: Windows). This isn't a "haha .NET bad" thing, it's just a reality. The same goes for the .NET Foundation. It's essentially still just a shell, controlled entirely by Microsoft. Again, no surprise, but a bit dishonest at the very least. > Myth 2: It’s Slower than Node/Python/Go/Rust A few examples where it can be marginally different (faster and slower) but nothing extreme that would make it 'the best choice'. This whole "my language is better because performance metric X" thing might make sense if we're talking orders of magnitude, but we're not (mostly). Also, the bust points out bandwidth, but here is a surprise: bandwidth matters a lot less when it's not the amount of bytes you need to have flowing, but the latency at which the flow starts. > Myth 3: It’s a Legacy Platform It's not a legacy platform because you can build new things with it, it's a legacy platform because everything .NET that is already out there is largely legacy. Ironically, this can work out both ways, since well-written C programs can both be legacy and current at the same time. But for .NET, the problem lies with the rather recent pseudo-community opening up and not with only the very last most recent .NET Core release. > Myth 4: The Tooling is Expensive It is still expensive because the good tools are always expensive. That is not always a bad thing, if you make money, good tools can be worth their money. But pretending that all tools are the same and therefore the expensive ones don't count as "the tooling is expensive" is not really honest. Again, if you were to make a new project, in isolation, targeting building a self-contained CLI application or API server, you can do that with any text editor. But we're not really exclusively writing code for those, are we? (more on this later) > Myth 5: .NET Isn’t Open Source Friendly It's looking friendly but is also very dishonest. See earlier text about the foundation (and earlier posts in HN about the same issue). > Myth 6: It’s for Boomer Enterprise Development Not sure how this myth came to be. Existing long-lived applications definitely start entering the Boomer Enterprise Development zone, but that applies to pretty much any language and framework that's been around for a while. See rant about greenfield development and the reality of existing software above. Now, don't get me wrong, none of this makes .NET explicitly good or bad, but it does smell like a "we are really good, why don't you love us" type of Myth-post. When you start a new, non-Desktop, non-GUI application with proven technologies, then .NET works fine, just like Go, Python, NodeJS and even Java. But in that same sentence, a problem pops up: it always irks me personally that you apparently can't say C# on its own. It's always C#, with a .NET Framework, and a .NET Compiler, and a .NET Runtime. None of that is really swappable, you can't just say "I want to use a different framework" or "I'd like to compile to a native binary". The "one true solution" doesn't exist. A compiler that wants you do use its one and only project management structure seems wrong to me. Perhaps nobody wants that anymore, or the concept of monoculture being generally bad hasn't landed everywhere yet, but when thinking about a concept of a language, a framework, a compiler and a runtime becomes muddy and developers generally cannot detect a distinction anymore, that just smells enterprise to me. And not in a good way.