C# is not even close to Java in term of libraries.

Which are missing? :)

There are currently 244,641 libraries through nuget

https://www.nuget.org/packages

Ps. You can use libraries from f#, c# and VB.net. So as a .net developer, your statement doesn't make any sense.

You could have mentioned the different frameworks. But there is interop through the CLR between languages.

Eh, I've been a .net developer for almost 15 years.

The parent post is correct that the third-party ecosystem (especially OSS) is sorely lacking in quality.

Like look at logging - logging in .net is SO anemic. Even with third-party libs, there are so many features missing that have been in java libs like slf and log4j2 for years, yet we have nothing close in .NET.

Hell, you could just pick a feature from spring and compare to what's available in .NET ecosystem, and you'll be sorely disappointed.

Can you give an example what is missing in e.g. Serilog?

The ability to change logging levels of either a category or all categories at runtime is one.

Being able to monitor levels via an administrative endpoint.

A decent rolling file implementation that can compress the archived files.

These are all things I've had to implement (on top of serilog, no less) in the past year.

log4j2 has these out of the box.

> The ability to change logging levels of either a category or all categories at runtime is one.

LoggingLevelSwitch?

> Being able to monitor levels via an administrative endpoint.

I wrote actuator endpoints for this one, was not hard but yeah.

> A decent rolling file implementation that can compress the archived files.

serilog-sinks-file has FileLifecycleHooks?. There's OOB serilog-sinks-file-gzip but you can also implement your own.

Nlog Elmah ( .net framework)

All the sinks for whatever you want.

Quantity of libraries is a poor metric. Like I said, the standard library in .NET covers a lot, and lets you make everything from CLIs to enterprise web apps. And when you do need 3rd-party code, there are plenty of commercial and OSS options to solve your problem.

It's not just quantity. Java benefits from all the major players that are using it. Quality of libraries is head and shoulders above anything you can find in .NET world.

I don't think so anymore. It used to be that way but .NET has massively changed in the last few years. Also many of the Java libraries are unnecessary in the .NET because of its strong standard library and core frameworks. There's no need for 20 different JSON serializers or webservers. In contrast, there's nothing even close to Blazor for Java.

Many of the .net libraries are poor afterthoughts of an existing Java library.

Java simply has developer mindshare, the .Net developer stereotype is so rigid and engrossed that the pay difference between a .Net dev and their Java peer is usually around 20% if not more.

your average .net dev gets paid less than your average COBOL dev too, but I wouldn't say that informs us of much other than scarcity of expertise. We used to say, "you can through a rock into a crowd and find somebody who can at least be productive on .net". Finding a stone cold expert on .Net is far more difficult, but for the average enterprise doing internal development weighing whether to adopt one platform or another, resource availability/scarcity matters.

The confusion here is perhaps that I jumped from B to F. The number of successful Opensource projects in Javaworld are astounding, and the OSS/Library work in .net is there but in comparison is miniscule. That feeds into the stereotype of .net developers being cookie-cutter VB-eseque Enterprise developers, which even feeds into their pay.

JavaWorld is bigger and Java developer count exceeds .net developer count, so the whole scarcity thing is a static explanation of a much complex dynamic environment. The intent here is not to complain about .net dev wages.

> your average .net dev gets paid less than your average COBOL dev too

I don't see how this is a valid comparison. Java being paid better has nothing to do with scarcity of expertise.

The comparison was to illustrate that scarcity of expertise absolutely affects pay rate, notwithstanding other explanations.

Whether that explains part or most or all of Java dev pay premium is at least debatable. For instance, I would never make the same "throw a rock into a crowd" statement about finding a competent (but not expert) java developer. That alone means I would expect to pay some of a premium for finding them in that crowd.

What's the counter argument to scarcity? Alignment with better paying industries, weighted so heavily in that direction that it shows up as a premium for their developers? I mean, if you start getting into the conversations about the obscurity of domains, or supplemental education associated with Java developers either by coincidence or requirement, or general demand, I think you're still commenting about scarcity.