3 ms·

I lightheartedly object to C# being mentioned in the same breath as the rest. I've been writing Windows Forms applications for 21 years. Most C# applications ha

I lightheartedly object to C# being mentioned in the same breath as the rest. I've been writing Windows Forms applications for 21 years. Most C# applications have fewer than 10 dependencies, and they tend not to have their own transitive dependencies. It's bliss. We just really don't have the same level of problems in this ecosystem.

sdflhasjd 4y ago
Yes, having originally been a C# developer and now diversified and had some experience in other tech, I realised that we are spoiled by one of the most robust standard library and suite of first party libraries that nothing else I've ever used has stood up to it.
- pjmlp 4y ago
  Java is the only ecosystem on comparable level, hence why both of them are my daily tools.
vikingerik 4y ago
I have to disagree, C# can be as bad too. I work on a medium-sized (~500k loc) C# codebase, and we get tangled up in dependency chains frequently. It's a web app with a number of integrations and API calls for things like Google/Facebook/Bing ads that each use some library from them, and other stuff like cloud storage calls and FTP file deliveries. They all tend to bring in more dependencies, like Newtonsoft Json parsing, Excel reader/writer classes, HTTPS and certificate management libraries, log4net logging. I spend a non-trivial amount of time sorting out version conflicts among these, even with the Nuget package manager doing most of the work.
- andyp-kw 4y ago
  I don't understand how any of the libraries you mentioned would cause dependency issues unless you're referencing them in a weird way. Nuget packages are usually compiled and self contained with their dependencies.
  - vikingerik 4y ago
    What happens is version conflicts. The dependencies often want to bring in conflicting versions of the grand-dependencies, the lower level libraries like Newtonsoft.Json and log4net and so on. There's a <bindingredirect> syntax in web.config or app.config that allows telling something to look for a different version. This usually works, and Nuget gets it right automatically most of the time, but occasionally there's a real conflict where a version isn't compatible and I spend a day a few times a year dealing with that.
codalan 4y ago
It depends. I've encountered C# apps with very few NuGet packages. And then there are the ones that pull in all sorts of logging libraries and abstractions, 3rd party DI frameworks, 3rd party ORMs, Newtonsoft JSON, and more! Fortunately, the trend is moving back to more centralized, MSFT maintained packages and libraries (EF Core, ASP DI, System.Json, etc.), which makes future maintenance less of a headache. The main issue I have with 3rd party packages (particularly with obscure ones) is vetting them out. Arguably, the same is true for pulling in MSFT libraries, but when serious security issues happen, you can expect MSFT to (eventually) resolve it. I don't really get that guarantee from 3rd party packages, which might have only 1-2 unpaid maintainers if you are lucky. If you are unlucky, the code might be abandoned and completely unreadable. I try to limit this risk by only using well-known, well-maintained packages, e.g. Serilog, and keeping package dependencies as minimal as possible.

sdflhasjd 4y ago

Yes, having originally been a C# developer and now diversified and had some experience in other tech, I realised that we are spoiled by one of the most robust standard library and suite of first party libraries that nothing else I've ever used has stood up to it.

pjmlp 4y ago
Java is the only ecosystem on comparable level, hence why both of them are my daily tools.

vikingerik 4y ago

I have to disagree, C# can be as bad too. I work on a medium-sized (~500k loc) C# codebase, and we get tangled up in dependency chains frequently. It's a web app with a number of integrations and API calls for things like Google/Facebook/Bing ads that each use some library from them, and other stuff like cloud storage calls and FTP file deliveries. They all tend to bring in more dependencies, like Newtonsoft Json parsing, Excel reader/writer classes, HTTPS and certificate management libraries, log4net logging. I spend a non-trivial amount of time sorting out version conflicts among these, even with the Nuget package manager doing most of the work.

andyp-kw 4y ago
I don't understand how any of the libraries you mentioned would cause dependency issues unless you're referencing them in a weird way. Nuget packages are usually compiled and self contained with their dependencies.
- vikingerik 4y ago
  What happens is version conflicts. The dependencies often want to bring in conflicting versions of the grand-dependencies, the lower level libraries like Newtonsoft.Json and log4net and so on. There's a <bindingredirect> syntax in web.config or app.config that allows telling something to look for a different version. This usually works, and Nuget gets it right automatically most of the time, but occasionally there's a real conflict where a version isn't compatible and I spend a day a few times a year dealing with that.

codalan 4y ago

It depends. I've encountered C# apps with very few NuGet packages. And then there are the ones that pull in all sorts of logging libraries and abstractions, 3rd party DI frameworks, 3rd party ORMs, Newtonsoft JSON, and more! Fortunately, the trend is moving back to more centralized, MSFT maintained packages and libraries (EF Core, ASP DI, System.Json, etc.), which makes future maintenance less of a headache. The main issue I have with 3rd party packages (particularly with obscure ones) is vetting them out. Arguably, the same is true for pulling in MSFT libraries, but when serious security issues happen, you can expect MSFT to (eventually) resolve it. I don't really get that guarantee from 3rd party packages, which might have only 1-2 unpaid maintainers if you are lucky. If you are unlucky, the code might be abandoned and completely unreadable. I try to limit this risk by only using well-known, well-maintained packages, e.g. Serilog, and keeping package dependencies as minimal as possible.