4 ms·

I havent use it a lot but my main issue with the language is 3rd party libraries. MS libraries are great but all the rest seem to be enterprise-milking, poor wr

by papichulo2023 2y ago

I havent use it a lot but my main issue with the language is 3rd party libraries. MS libraries are great but all the rest seem to be enterprise-milking, poor wrappers or sdk for some cloud service. The other one is that it is not always clear the context on which you can use certain APIs.

highwaylights 2y ago
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).
Const-me 2y ago
> all the rest seem to be enterprise-milking, poor wrappers or sdk for some cloud service Here’s 8 third-party libraries I have published on nuget in the last ~7 years: https://www.nuget.org/profiles/ConstMe https://www.nuget.org/profiles/ConstMe Only one of them is an SDK for a cloud service, but it’s unofficial SDK. I have no affiliation to pcloud, I only use the free version, I just carefully implemented the documented TLS/TCP binary protocol to access their cloud.
- papichulo2023 2y ago
  Hey great! Meant no offense. I was talking about what I saw when I tried to start a computervison project in c# like 2 years ago. I am sure there quite a few good libraries.
  - Const-me 2y ago
    > Meant no offense None taken. > computervison project in c# Yeah, for CV applications nuget.org is indeed not particularly great. Very few people are using C# for these things, people typically choose something else like Python and OpenCV. BTW, same applies to ML libraries, most folks are using Python/Torch/CUDA stack. For that hobby project https://github.com/Const-me/Cgml/ https://github.com/Const-me/Cgml/ I had to re-implement the entire tech stack in C#/C++/HLSL.
hnthrow289570 2y ago
>MS libraries are great but all the rest seem to be enterprise-milking, poor wrappers or sdk for some cloud service. The biggest example are PDF producing/converting libraries, which I have no doubt make millions in licensing.

highwaylights 2y ago

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

Const-me 2y ago

> all the rest seem to be enterprise-milking, poor wrappers or sdk for some cloud service Here’s 8 third-party libraries I have published on nuget in the last ~7 years: https://www.nuget.org/profiles/ConstMe https://www.nuget.org/profiles/ConstMe Only one of them is an SDK for a cloud service, but it’s unofficial SDK. I have no affiliation to pcloud, I only use the free version, I just carefully implemented the documented TLS/TCP binary protocol to access their cloud.

papichulo2023 2y ago
Hey great! Meant no offense. I was talking about what I saw when I tried to start a computervison project in c# like 2 years ago. I am sure there quite a few good libraries.
- Const-me 2y ago
  > Meant no offense None taken. > computervison project in c# Yeah, for CV applications nuget.org is indeed not particularly great. Very few people are using C# for these things, people typically choose something else like Python and OpenCV. BTW, same applies to ML libraries, most folks are using Python/Torch/CUDA stack. For that hobby project https://github.com/Const-me/Cgml/ https://github.com/Const-me/Cgml/ I had to re-implement the entire tech stack in C#/C++/HLSL.

hnthrow289570 2y ago

>MS libraries are great but all the rest seem to be enterprise-milking, poor wrappers or sdk for some cloud service. The biggest example are PDF producing/converting libraries, which I have no doubt make millions in licensing.