Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

.NET Developers Begging for Ecosystem Destruction

aaronstannard.com

Post reply on HN
Print view View original

21–30 of 31 posts

Re: .NET Developers Begging for Ecosystem Destruction

#21

Post by devwastaken »

pjmlp wrote: post #6

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, libr…

.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.

Re: .NET Developers Begging for Ecosystem Destruction

#23

Post by littlecranky67 »

kennethh wrote: post #8
littlecranky67 wrote: post #5

Earlier quoted context omitted.

> 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 allo…

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.

Re: .NET Developers Begging for Ecosystem Destruction

#24

Post by neonsunset »

devwastaken wrote: post #21
pjmlp wrote: post #6

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, libr…

.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).

Re: .NET Developers Begging for Ecosystem Destruction

#25

Post by victorNicollet »

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".

Re: .NET Developers Begging for Ecosystem Destruction

#26

Post by pjmlp »

neonsunset wrote: post #24
devwastaken wrote: post #21

Earlier quoted context omitted.

.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?

Re: .NET Developers Begging for Ecosystem Destruction

#27

Post by neonsunset »

pjmlp wrote: post #26
neonsunset wrote: post #24

Earlier quoted context omitted.

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...

Re: .NET Developers Begging for Ecosystem Destruction

#28

Post by kieranbenton2 »

devwastaken wrote: post #21
pjmlp wrote: post #6

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, libr…

.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.

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

Re: .NET Developers Begging for Ecosystem Destruction

#29

Post by jinushaun »

stereopixels wrote: post #4

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 sol…

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

Re: .NET Developers Begging for Ecosystem Destruction

#30

Post by styx31 »

littlecranky67 wrote: post #5
stereopixels wrote: post #4

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 sol…

> 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 allo…

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.
Post reply on HN