3 ms·

This to me is the biggest drawback. The language is truly lovely to work in, moreso than I think it gets credit for unless you've a lot of experience with it.

This to me is the biggest drawback. The language is truly lovely to work in, moreso than I think it gets credit for unless you've a lot of experience with it. It's just very thoughtfully designed, and MS support their own components really well and for a very long time. The problem is that NuGet never became npm, gem or pip. The open-source community never really embraced C# (for understandable reasons) and it meant that the void there was filled largely by projects that couldn't get much traction and enterprise component vendors like Telerik. I'm not in any way knocking companies that make their money selling these components by the way, I just think the message that people looking from the outside are seeing (rightly or wrongly) is that there's a tax payable to third parties on absolutely every level of this stack so why build with it? What's my incentive to start learning it when I can pick up node / React / Next / Python / etc. for free and start working right away with free tools? And that all shows in the ecosystem.

neonsunset 2y ago
You must be joking if you refer to npm packages or ruby gems as examples of good and healthy (!!!) ecosystems. OSS adoption is an ongoing process, that doesn't happen overnight. The attitude in this and adjacent comments is a good showcase that even after 8 years, once your average developer has settled in a particular mindset, it becomes a matter of enforcing tribal consensus even when the facts change. If you also ever actually used .NET and nuget packages (in a post-netframework period), it would be apparent that the statement is simply not true.
- highwaylights 2y ago
  Respectfully: I’ve used both quite a bit, and have used .NET since the first release. If I need a package to perform a task that I think other people surely must have brushed up against in the past then I know it almost certainly exists in npm. That’s just not true for NuGet, as much as it would be better for the ecosystem if it was. This shows in the contributions to each, and the contributions (in terms of volume) are much higher for npm.
  - neonsunset 2y ago
    Nuget did not exist until around .NET Framework 4.0 (which was 14 years ago). I specifically noted the post-.NET Framework experience. It is a continuous problem that community demands from the standard library and/or sdk to ship something it has no business shipping (like the sibling comment complaining about System.Drawing, it is truly an 8th OSI layer issue). And when there's an OSS solution, there is a stark difference in comments between developers who understand that OSS projects are projects of collaborative development (meaning that submitting and issue you care about may involve a degree of contribution) and the ones which demand paid level of support for free. JavaScript is also just generally massive. Surely you're not going to hold it against Rust that Rust projects are less frequently contributed to? C# and .NET are unique language and platform which do overlap with Java and JVM, and other similar class of tools but do solve problems the latter cannot, or solve the ones that they can but in a frequently better way (for example: trying to reach performance ceiling in Java requires way uglier tricks with worse results rather than writing clean byref/pointer based C# code with structs and struct generics).

neonsunset 2y ago

You must be joking if you refer to npm packages or ruby gems as examples of good and healthy (!!!) ecosystems. OSS adoption is an ongoing process, that doesn't happen overnight. The attitude in this and adjacent comments is a good showcase that even after 8 years, once your average developer has settled in a particular mindset, it becomes a matter of enforcing tribal consensus even when the facts change. If you also ever actually used .NET and nuget packages (in a post-netframework period), it would be apparent that the statement is simply not true.

highwaylights 2y ago
Respectfully: I’ve used both quite a bit, and have used .NET since the first release. If I need a package to perform a task that I think other people surely must have brushed up against in the past then I know it almost certainly exists in npm. That’s just not true for NuGet, as much as it would be better for the ecosystem if it was. This shows in the contributions to each, and the contributions (in terms of volume) are much higher for npm.
- neonsunset 2y ago
  Nuget did not exist until around .NET Framework 4.0 (which was 14 years ago). I specifically noted the post-.NET Framework experience. It is a continuous problem that community demands from the standard library and/or sdk to ship something it has no business shipping (like the sibling comment complaining about System.Drawing, it is truly an 8th OSI layer issue). And when there's an OSS solution, there is a stark difference in comments between developers who understand that OSS projects are projects of collaborative development (meaning that submitting and issue you care about may involve a degree of contribution) and the ones which demand paid level of support for free. JavaScript is also just generally massive. Surely you're not going to hold it against Rust that Rust projects are less frequently contributed to? C# and .NET are unique language and platform which do overlap with Java and JVM, and other similar class of tools but do solve problems the latter cannot, or solve the ones that they can but in a frequently better way (for example: trying to reach performance ceiling in Java requires way uglier tricks with worse results rather than writing clean byref/pointer based C# code with structs and struct generics).