I am a relatively recent transplant from C# to Java. I'm still getting my bearings, but my general sense is that Java has an amazing ecosystem in the large scale, and that makes it much easier to tackle the hard problems, but is the absolute pits to work with for everyday challenges. IOW, Java makes the hard problems easier and the easy problems harder.

Concrete example: .NET has nothing comparable to the Hadoop ecosystem, or to International Components for Unicode.

Concrete example: Compared to what's in .NET, a lot of stuff in the core Java libraries feels very half-baked. Streams, for example is missing a lot of useful features that I am used to seeing in every comparable library. There's not even a mapi in there. Bifurcating it from iterables and the rest of the collections API also creates some ergonomic annoyances that don't exist in, e.g., .NET or Scala's equivalents.

From what I recall .NET has built in almost all of International Components for Unicode features. You can still use ICU from C# if you want to, but I have never personally seen anyone do so.

See: GenICUWrapper A tool that generates a rudimentary C# wrapper around the C API of ICU4C. ICU Dotnet - .NET bindings for ICU http://site.icu-project.org/related or https://github.com/sillsdev/icu-dotnet

There are also .Net options for Hadoop so I am not sure what you mean exactly?

There are options, there are always options, but they are typically 2nd class, incomplete, poorly supported, or otherwise substandard.

For example, first line of the readme for icu-dotnet (emphasis mine):

> icu-dotnet is the C# wrapper for a subset of ICU4C

ICU4C has quite a bit of cruft at this point, so the useful subset is perfectly reasonable. You can always add anything to these layers you want, but it's really not worth the effort.

I use both and you are right. As language C# fixes many things one could be unhappy with in Java. But Java has it's eco system which is definitely unmatched in quality and quantity...and that plus the ultra optimized and battle-tested JVM is what makes people stick with it.

That was more true a decade ago. The feature gap has narrowed a lot in recent years.

I'd also argue the JVM in general is still a better platform than the CLR.

I don't use it, but I know that I see a lot more job postings in my area for C# coders than Java coders.

Out of curiosity, what's your area? In SV it's Java shops as far as they eye can see.

From what I've seen, it varies wildly with the job market.

I'd expect to see more Java shops in SV because Java's huge open source ecosystem makes it a much better platform for doing, for lack of a better term, "tech company stuff." Also, SV is heavily influenced by academia, where .NET was just a flat-out no go for a long time because it only really worked on Windows.

But I see a lot more .NET for the kinds of in-house enterprise development jobs you see in regions like the Midwest. For that kind of work, there's usually not much in Java that you can't get on basically any other platform, too, and .NET/C#'s better ergonomics will let your team be more productive at the kinds of stuff they're doing. (I'd bet Clojure is even better still, but Clojure doesn't look good in khakis and a polo shirt.)

You're not the first one to mention it to me, but what "better ergonomics will let your team be more productive"? Honest question since, as an outsider to C#, the library ecosystem seems anemic coming from java.

So my sense is that, for utility-type stuff, the library ecosystem in Java feels bigger because its standard library is anemic. That basically forces Java to have a bigger library ecosystem just to achieve the minimum set of tooling you need just to hit the minimum bar for being a usable general-purpose language.

Joda Time, Apache Commons & Guava, Jersey, Hibernate, etc. - heck, even Dropwizard - are all libraries whose .NET equivalents are just different bits of .NET itself. Similar for Java Mission Control, for that matter.

Where .NET pales, IMO, is for stuff like Hadoop that, while astoundingly helpful for some problem domains, isn't so useful for most enterprise development work.

Connecticut