5 ms·

I won't argue over particular features because clearly it's a matter of personal preference and, working on OpenJDK, I'm biased, but a couple of points: Since

by pron 7y ago

I won't argue over particular features because clearly it's a matter of personal preference and, working on OpenJDK, I'm biased, but a couple of points: 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. Leaving aside the JDK 7 years (2006-2011) when Sun was struggling and then going through an acquisition, the rate of innovation on the Java platform is quite high. It's just that we emphasize other parts of the platform more than the Java language because that's where Java has always believed most of the value is. In the past five years Java has seen an exceptional new low-overhead, extendable profiling capability (JFR), groundbreaking new GCs (ZGC), and what is probably the biggest breakthrough in compilation technology of the past decade (Graal). Those are all huge developments, none of them affecting the frontend language in any way. An innovative, state-of-the-art runtime programmed with an intentionally conservative language has been Java's strategy from the beginning -- James Gosling called it a wolf in sheep's clothing (https://youtu.be/Dq2WQuWVrgQ https://youtu.be/Dq2WQuWVrgQ) -- and it has worked quite well. One could argue that that's the only way to sell a wolf to such an industry. Indeed, despite some grumblings on HN, it seems like most software developers prefer it this way.

snuxoll 7y ago
I have no love lost for Java the language, I find it cumbersome as hell to work in and as such all of my JVM work is done in Kotlin, but I appreciate having conservative and well-thought our evolution of platform features that ultimately effect all JVM languages; seeing as Java The Language is heavily tied into JVM semantics. Quite frankly even with all the new features Microsoft has been putting into C# they’ve been prime to ignore the existing implementations in F#, leading to a clusterfuck of an ecosystem where I can’t use many C# libraries in my language of choice due to conflicts in implementation. I don’t have that on the JVM, I know I can use a Java library in Kotlin, Scala, Clojure, hell even Ceylon without huge headaches because they all share the same primitives. Let other JVM languages incubate need language features, Java needs to be where they are eventually stabilized and standardized in how they work on the platform.
BoorishBears 7y ago
>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.
- pjmlp 7y ago
  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 7y ago
    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.

by pron 7y ago

snuxoll 7y ago

I have no love lost for Java the language, I find it cumbersome as hell to work in and as such all of my JVM work is done in Kotlin, but I appreciate having conservative and well-thought our evolution of platform features that ultimately effect all JVM languages; seeing as Java The Language is heavily tied into JVM semantics. Quite frankly even with all the new features Microsoft has been putting into C# they’ve been prime to ignore the existing implementations in F#, leading to a clusterfuck of an ecosystem where I can’t use many C# libraries in my language of choice due to conflicts in implementation. I don’t have that on the JVM, I know I can use a Java library in Kotlin, Scala, Clojure, hell even Ceylon without huge headaches because they all share the same primitives. Let other JVM languages incubate need language features, Java needs to be where they are eventually stabilized and standardized in how they work on the platform.

BoorishBears 7y ago

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

pjmlp 7y ago
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 7y ago
  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.