.NET Developers Begging for Ecosystem Destruction | Hacker News Reader

.NET Developers Begging for Ecosystem Destruction

aaronstannard.com

48 pointsnf1729 comments

The old saying one doesn't get fired by buying IBM also applies to Microsoft, Apple, Google, Sun/Oracle.

You see this on the Android ecosystem, until Google finally started pushing common set of libraries on AndroidX, later Jetpack, everyone used to complain about lack of direction on how to develop apps.

The full experience on a box from Apple platforms.

While the author rightfully points out Java isn't as bad, libraries that aren't part of Apache foundation, Java EE/Jakarta EE compliant, or Spring (which also includes a subset of EE JSRs), usually are largely ignored.

As polyglot dev that uses .NET, what is disappointing is how the whole .NET FOSS turned out to be, not necessarly what is happening with .NET 9 per se.

We have key team members trolling the community that Windows/Visual Studio is the best experience, which it is, because they killed the VS4Mac, VSCode plugins are still not as good as Python/Java from other Microsoft teams, now replaced by C# Dev Kit with the same licensing scheme as Visual Studio. The poor F# gets Ionide as good as they can manage.

Anyone that is unhappy with this experience outside Windows, has to buy Rider, versus other language communities that can jump into InteliJ Community, Eclipse, Netbeans without paying a dime (donations are welcomed for Eclipse and Netbeans).

Then we have the GUI mess, thankfully there are Uno and Avalonia now, or how Azure is driving ASP.NET design, which on the other ecosystems is indeed driven by collaborations and not really single vendor.

.NET with vscode C# extensions has not worked on Mac for some time. It's broken and cannot debug, it also features a fun warning from MS that their tools are proprietary.

Theyve really botched it and I can't find any reason to reach for poor quality tools over existing OS ones.

What? I am using it in parallel to writing this comment. Without DevKit just plain C# extension (but newer Roslyn LSP).

With or without the features that require VS Professional licence?

Commercial license is not required for the plain C# extension, which is distributed under a custom license for extension install[0] and under MIT for source code[1].

The features of DevKit (which is uninstalled on my system) are as follows[2]:

- VS-style solution explorer

- VS-style test explorer

- Intellicode (extra extension that integrates with DevKit)

I don't have use for any of these, preferring folder style navigation and CMD+T/P/etc., and GitHub Copilot autocomplete does way better job for any text than Intellicode. The "intellisense" VS calls it is just a base autocomplete feature in VSC that works for any language provided it has a back-end that integrates through LSP.

[0] https://github.com/dotnet/vscode-csharp/blob/main/RuntimeLic...

[1] https://github.com/dotnet/vscode-csharp/blob/main/LICENSE.tx...

[2] https://marketplace.visualstudio.com/items?itemName=ms-dotne...

They work perfectly, certainly since Devkit went GA back in Oct 2023 - use them on a M2 Macbook Pro every day.

Running with the dotnet executable works, debugging in vscode does not. It's readily reproducible and likely an effect from an obscure and common issue. (Maybe the "proprietary" nonsense) I could dig in and waste my time on the issue tracker, but I'm not the mega corp with a money printer.

Microsoft has many low quality teams, especially in some of their dev tooling. The natural consequence is that it's primarily tested on Windows, and has evolved many failure edge cases on other platforms.

The proper conclusion is - c# is for windows, just how it's always been. Using it is selling the business's products to Microsoft and forever ties it to their endless tech debt.

> There’s also the “our lawyers made us choose our technology stack” excuse, the enterprise version of “the dog ate my homework:”

This is a real thing. Even if you think including complex random unaudited opensource software with huge attack surface doesn't endanger your security, it does significantly increase the amount of work you need to do if you want ISO 27001 or similar cert

> significantly increase the amount of work you need to do if you want ISO 27001 or similar cert

Not true in my experience. We used a lot of "open source" software at work but that didn't matter in the certification. Maybe it depends on the auditor.

There are still engineers (mostly engineering directors) who, TO THIS DAY, hate open-source and perceive it as a threat. That's absolutely wackadoo to me. Most of these types are all-in on Microsoft, so this attitude being pervasive within .NET isn't surprising.

It's the main reason I never liked .NET and I feel like a lot of .NET proponents suffer from Stockholm syndrome. The argument that having few options would actually be a good thing is so absurd.

It's not a .net thing, it's analysis paralysis that was known before Aesop.

I'm a .NET developer, and honestly, this is the worst part of being one; we get good third party tools, we get promises from Microsoft about them being all about open source, and Microsoft constantly move in and obliterate all the competition; there are countless examples out there. A few years ago we had a great amount of choice around DI containers for example - they filled an obvious gap Microsoft had given no solution at all for within their framework despite its many years of existence. Then one day they come along with a DI container that is far inferior to the existing offerings, but it's the default on a new project... the whole community immediately stays with this default option despite the obvious inferiority. Today I never find any modern .NET apps using anything other than this default, and I still think it's inferior to what we had.

Microsoft have always adhered to 'Embrace. Extend. Extinguish', and it is alive and kicking today in every area of open source they touch, be it this, GitHub, Windows Subsystem on Linux... they have no real interest in open source, except to crush it as best they can.

> one day they come along with a DI container that is far inferior to the existing offerings

Microsoft baked-in DI is purposefully designed to be as minimal as possible, such that you can start quickly without getting into too much abstractions. And once you reach a level where you need a more powerful (and thus complex) DI container, you can easily plug it in and seamingly bridge within the minimal MS one. This allows to migrate in iterations to your DI container. And from my experience, the built-in one is enough for a lot of basic usecases.

Plus, it is way easier to move a codebase from MS-built in DI to any other 3rd party DI, than to move a codebase which grew without DI at all.

There is a reason why there is a ton of DI containers out there (Autofac, Funq, NInject, CastleWindsor, StructureMap etc) and ALL are differently opinionated and made different design decisions. What would have been your suggestion for MS, which one to bake into the ASP.NET Framework? There is NO way you pick any and not upset the people on the other side of the fence. IMHO MS did the right way, and tried to go with a minimal version that shares a common denominator with all of them, so they can be easily plugged in when needed. This is exactly what having choice means.

What would you recommend as an easy upgrade from the default DI?

What do you mean? If you need an upgrade from the default DI, then YOU should ask yourself why do you think you need it, gather requirements, identify what is missing from the existing solution, and chose one of the many DI container based on your needs and findings. And most of those containers can be used with MS existing DI pipelines.

Perfect anwser. I have used DI for years, and the common DI abstraction is a great features: it allows people to start using DI and allow MS to use it internally, then, if you find it too limited or like some custom features, then start using a custom one, which is a breeze.

I don't think EEE applies to killing off unmaintained, underused and extremely badly written DI containers like Unity DI or Autofac. Honestly, both can burn in hell. And nowadays M.E.DI isn't the sole choice and there is a rich set of alive and well DI frameworks to use depending on your needs.

I used to do a lot of .NET. That’s the community’s fault, not MS.

For me it's biggest advantage of.NET that it have "just works" defaults. I prefer it from Java ecosystem when you have many options and each every one has basic problems with even the setup.

The experience I have of working in C# and .NET is that you use everything from Microsoft, even if it sucks. It's like a rule that goes through every "Microsoft shop" out there.

They are as much of zombies as the apple fanboys are. It doesn't matter what the company do, they will buy it and lick it up like they were a cat licking cream from a platter.

> They are as much of zombies as the apple fanboys are. It doesn't matter what the company do, they will buy it and lick it up like they were a cat licking cream from a platter.

My cat is much pickier about his cream than tech fanbois are about their stack choices.

> This is something that doesn’t really happen in other software ecosystems.

Author has clearly never met an iOS developer

The author blames "senior developers" for library usage policies. I've been a senior (now principal) developer for well over a decade and we've never had a single say in anything like that. That's when the compliance team and the lawyers get involved.

I can't argue with most of the rest of it though.

.NET is only just fit for purpose, still. Azure is atrocious. I didn't choose any of this, it's our CTO who decided we'd build our new platform on Azure, with loads of support from Microsoft promised.

Hah.

At least I get to solve interesting problems - and they'd be interesting and difficult on any platform.

you have lawyers sign off your libs?

this is fairly common in the gov and financial sectors (but it's enterprise architects or security engineers doing the signing)

What industry do you work in? I’ve done the gamut of regulated industry work - medical, defense, banking etc, and never run into this. Aaron is (as usual) spot on with his analysis.

I'm a maintainer for an open source .NET library that, ironically, only exists because it provides a feature that Microsoft removed from .NET during the migration to .NET Core.

Very rarely have I needed a library to solve a problem, and found that a library from Microsoft was even available at all.

AspNetCore is its own world inside the greater .NET universe. It is a web framework with a "batteries included" philosophy, and it's not unusual for users of those to want all their use cases covered by the framework itself. The original article laments AspNetCore introducing its own dependency injection system, but this is par for the course in languages that care about dependency injection (see PHP's Laravel and Symfony, or Java's Spring). As for AspNetCore developers only knowing Entity Framework, the same argument could be made about 'db' in Django or 'ActiveRecord' in Ruby on Rails.

The philosophy of "It is good that I no longer have to use a separate tool for what should have been a feature of my framework" is understandable, and it's a bit disingenuous to describe it as "It is good that I have fewer choices available to me"

And it's also a bit disingenuous to describe AspNetCore users commenting on an AspNetCore feature announcement in the AspNetCore GitHub repository as ".NET Developers".

Microsoft gonna Microsoft.

And people who have gone all-in on the Microsoft ecosystem are... a special bunch. I sat in on a meetup with some of them once and it soon became clear that I was in a room full of Morts on Microsoft's own Mort-Elvis-Einstein scale. The concept of using variables in PowerShell scripts seemed to mystify them. No surprise then that that sort of person would be terrified to use anything not blessed by the Holy See-Sharp in Redmond.

It's kind of a shame because open-source .NET is really kinda nice. No real C# language support in Emacs, though, and barely any in VS Code without going for the proprietary stuff.

Reply on news.ycombinator.com