[BoorishBears]

>Since Java was introduced in 1995 until today, Microsoft's software framework has had about three or four drastic backward-incompatible "generations", depending how you count. Most Java code written in 1995 will run, with little or no change, on the current JDK 13, and would compile on JDK 13 with only minor changes.

That's exactly what's wrong with Java.

That's why we got "functional interfaces" instead of proper lambdas.

That's why we got half baked generics.

That's also exactly what I'm praising C# for.

They've paid that price 4 times, and every time they added so much value that it was easily worth it to their users.

Ask the average C# developer if they'd trade for Java's half baked lambdas and generics alone for none of those generations happening, and you'd get a resounding, no way in hell.

And C# stayed relevant in enterprise despite it, I've never seen an enterprise say "we're choosing Java because 4 times since 1995 they decided to add features so incredibly powerful language features and broke backwards compatibility.

The places that couldn't handle the changes needed are also the ones that would keep running an old runtime (and old JVM if they're using Java, because any upgrade = risk, backwards compat claims or not) as long as they want, security be damned.

.NET has an insane amount of "under the hood" innovation that has happened as well in all that time by the way, I'm speaking to the programming languages, not the runtimes and platforms that enable them. It's fairly straightforward to compare language features because they started in such similar places, comparing runtimes is a much less direct comparison.

[pron]

Whether that's "wrong" or "right" is a matter of opinion. But it's hard to argue with the fact that many more people seem to prefer Java's approach to Microsoft's. As to .NET's "insane under the hood" innovation, the platform is similar to what Java was about 10-15 years ago in terms of GC, JIT compilation and monitoring. .NET prefers changing the language, while Java prefers changing the platform. The two just have a different DNA. I've always felt that while there's a clear bottom-line "business" advantage to improving performance or observability, language features are almost always questionable because we can't find any evidence they make a real difference in practice. The main difference it seems to make is in the number of developers who vocally love or vocally hate a particular feature, and in giving a feeling of "vibrancy" to developers who perhaps sometimes care about their code more than about the program it's part of.

[phillipcarter]

I’d recommend spending some more time with .NET Core and comparing its performance characteristics (as of .NET Core 3.1). I think you’ll find it compares quite favorably, with recent advances like Span making a big difference. While it’s accurate to say the CLR has been behind on the desktop for a long while, the rekindled effort around advancing the runtime in .NET Core has paid off in spades and has only really just begun. It sounds like your impression is rooted in the desktop CLR, which is effectively frozen for compatibility reasons.

[pron]

I'm sure it has, but in the meantime Java is making great strides as well on multiple important fronts -- low-latency GCs, a next-gen JIT, AOT compilation, native ffi, low-overhead in-production profiling and lightweight concurrency, and the main problem with Microsoft's technologies remains that they break compatibility every five-six years or so. Now it's .NET Core, and it wouldn't be a bad bet to guess that in five years it will be something else. We're at a point where it's so hard to make changes with a big bottom-line impact (arguably there weren't too many such advances in the past twenty years) that very few actually justify breaking compatibility, and companies know that. So while smaller software can afford switching from one technology to the other, big "important" stuff requires a compatibility lifespan of at least ten if not fifteen years, something that Microsoft has never been good at. It's possible that with their focus shifting more to the backend with their cloud offering that would change, but it appears that their cloud strategy is to support all software platforms rather than focus on their own. That's why we see Microsoft now hiring engineers, as well as getting some CLR engineers, to contribute to Oracle's OpenJDK [1].

[1]: https://mail.openjdk.java.net/pipermail/discuss/2019-October...

[phillipcarter]

> something that Microsoft has never been good at

Well, you're certainly entitled to that opinion :)

As I said, I encourage you to explore .NET Core and its recent advances, especially now that the big runtime improvements made in recent years have proliferated throughout the standard library and new language features. While it's fair (and correct) to say that the Java runtime is ahead due to many years of focused improvements, I think you'll find the difference quite a bit smaller than it was back when .NET was focused mainly on Windows desktop software.

[pron]

I believe you re .NET Core, but I think that Microsoft shifting their focus to a backward-incompatible development platform (not Windows, on which they have a very good compatibility record) every five years or so is more than just opinion. I think that their record on that front speaks for itself. If you were a developer who always uses the current flagship MS development platform to develop a piece of software that you first wrote in 1999, by now you'd be on your fourth significant rewrite. TBF, Java also made one such misstep, with JavaFX Script in 2009, but that was corrected and reverted.

[phillipcarter]

That may be your impression. I'm only speaking from experience here, where we have done things like investigate issues with the first public release of a compiler for a week to ensure behavior is still correct when used in a newer environment.

But it's important to distinguish where we are now - .NET Core being explicitly cross-platform, vendor neutral, and OSS - from where .NET was. .NET Core is not tied to a specific product or initiative (e.g., Silverlight) that could go down due to other market forces and take that flavor of .NET with it. This is the position that Java has been in for a long time. Perhaps you or others you've known have been burned by buying into a Windows Mobile Flavor of the Month only to see it canned a few years later, so it's not unreasonable to think that the same could happen here. But at the same time, .NET Core has been going for 5 years now, and over that span of time it's only become more compatible with existing APIs and runtime environments, not less.

[BoorishBears]

Haha, the way you just handwave away the last few years of .NET/CLR/Roslyn/DLR changes means I've seen this is a waste of my time and will stop checking for replies

But uh yeah... what percentage of Java developers are still on Java EE 7, 8?

The "business advantage" is in things not changing. If you compare languages by business advantage then Java 1 wins because "we haven't had to waste money upgrading since the 90s!"

I'm going for something a little more meaningful, developer ergonomics, which you hand-wave away as not being valuable to a business (protip: if your developers get to care about their code that's a good thing, you'll find you can get better developers if you look for the ones who do)

[pron]

Putting aside which platform has better developer ergonomics -- something that's obviously very subjective -- you think that linguistic features that have not been found to make any significant impact are "more meaningful" than things that make software more valuable just because you feel very strongly about that? Also, seeing that I've been a professional developer for more than a couple of decades now, I hope you'll forgive me if I ignore your "pro" tip. Programmers who care about code are, indeed, often better than those who care about nothing at all, but if you want to hire good developers, you'll hire those who care about the product more than about code. They'll be much more expensive, though.

[ivanche]

> But uh yeah... what percentage of Java developers are still on Java EE 7, 8?

I hope around 90% or more, because Java EE 8 is the latest version of Java EE.

[BoorishBears]

Java (EE 7 or 8)...

[pjmlp]

Not all enterprises enjoy going through .NET rewrite cycles (Silverlight, WinRT, UAP, UWP, .NET Core).

To the point that in 2016 I got a couple of RFP to port from C# into Java for UNIX portability, in spite of .NET Core also being an option already.

Their reasoning being that with Java it would be a safer bet, while they couldn't be sure if .NET Core would ever be the last rewrite.

[pas]

It's perfectly possible to separate the language changes from the mindless API/platform/ecosystem churn.

.NET Core finally considers Linux, the server OS, which brings it to parity with the JVM. Will this be the final rewrite? Who knows.

Plus there is a lot of churn in Java land too (new libraries, rewrites of old libs, streams, libs becoming unmaintained, etc.), just big corps don't ever do any real maintenance.

I would probably opt to use Scala or Typescript instead of C# anyway. And Rust if there's some performance critical part.

[pjmlp]

The big difference that many .NET Framework libraries won't work on .NET Core, and even less on Linux, because they depend on C++/CLI, Win32 interop or COM.

Then those corporations start to evaluate a rewrite to portable .NET Core and come to the conclusion that several third party components also don't work on .NET and they need to go shopping.

In the same process, they find out that said components actually have a perfectly working counterpart for Java since Java 1.4 or something.

And a new RFP goes out.

As for what to opt for, platform languages are always the best bet longterm.

As long as the platform is relevant on the market they stick around, guest languages come and go, and tend to be insignificant outside the platform where they have guest status as they have to reboot an whole new platform experience.

[pas]

Sorry, I worded my comment imprecisely. I meant the CRL and language feature developments can and should be looked at separately from the platform/ecosystem stuff.

I'm aware that Core is different, and that MS only ported a subset of their APIs, and thus many libs need to be completely rewitten, especially those that were already just wrappers/helpers for more Win32-specific things.

And this wrapping platform specific lower lever libs happens on other ecosystems too. Python users run into this quite a lot, Rust devs too, etc. And many early Java programs were basically platform specific, even if the JRE itself was not.