Hacker News new | ask | show | jobs
by pron 2383 days ago
> To me the moment you're trying to defend Java generics and type erasure, vs C# which paid the price early and has reaped the rewards for years, you should already you're on the wrong side of things...

Those erased generics that you call "half baked" are the reason why language interop works so much better in Java that in .NET. The combination of subtype polymorphism and parametric polymorphism means choosing a variance strategy. If you reify generics with subtypable arguments that means that you must bake a variance strategy into the platform -- which is what .NET has done -- even though languages have very different ones (in particular, untyped and typed languages will have different variance). So on the Java platform, the Java language, Kotlin, and Clojure all have different variance, yet they can share data structures with no runtime conversion. The cost of this platform compatibility is exactly three very minor annoyances [1] in the Java language. For the price of these three minor annoyances, the reward Java has reaped is a large polyglot ecosystem that's a favorite of language implementors. The Java language, too, the one with those actual three minor inconveniences, is also much more popular than C#. So overall, I think it is hard to argue that C#'s rewards from reified generics are greater than Java's from erased generics.

It really doesn't take much of an effort to defend Java's choice once you know what the ramifications are and what the results have been. Partly because of the mistake of reified generics, .NET is de-facto a one-language platform. The language, like most programming languages, is fine, but given Java's growing emphasis on being one of the best runtimes for Python, Ruby and other languages as well, it's very clear that the two platforms have very different goals. Reifying subtypable generics is a good choice for a one-language platform but a bad choice for a polyglot one.

[1]: In order of decreasing annoyance: no overloading by generic argument, no `new T[]`, no `instanceof List<String>`. All three are very minor concerns, and the last is possibly even an antipattern.

1 comments

You're seriously overselling how much value non-Java JVM based languages are bringing to the ecosystem...

Java is still the only JVM language with more than 1% usage on any industry ranking of languages.

All non-JVM languages combined represent 10% of JVM usage

https://snyk.io/blog/jvm-ecosystem-report-2018/

As someone who writes a lot of Kotlin for a living, something like 80% of the improvements Kotlin brings that I use on a day to day basis are features to give it the same level of ergonomics as C#... like reified generics...

-

And your comment that .NET is a de-factor one-language platform makes it sound like you've never heard of the DLR (or F# and VB for that matter)

To me the biggest reason DLR languages are not as big as things like JRuby is C# is a pretty damn good language. There's much less value is trying to cobble together existing languages and subpar runtimes when the defacto language is modern, developing at a steady clip, and "delightful" to use.

Those under-10% Java market-share languages would make up about half of .NET's. Everything looks small in comparison when you're as incredibly successful as Java (some of those languages you find so insignificant are about as big as Go, much bigger than Rust, and probably 10x as big as Elixir or Haskell). I just find it funny to argue that second-tier products (in terms of popularity) know about "value" more than leading ones. And none of that changes Java's focus and strategy as a polyglot runtime. Java is already on its way to be the best Python runtime, and it's getting competitive with the very top JS runtimes out there.

You can argue over language preference, as some programmers do, all you like. I have very different preferences from yours, and many other programmers have preferences different from the both of us and that's OK. You say you prefer programming Java in Kotlin rather than the Java language? That's pefectly fine and part of Java's strategy for the past 20 years. The Java language is intentionally conservative because it seems many more people like conservative, slow-changing languages, but the Java platform will make sure that it runs Clojure, Kotlin, JS, Python and Java language programs as well as anything.

Ugh, I started reading this before I realized it's the same person who thinks C#'s under the hood improvements in the last decade can be handwaved away.

Yeah, 10% of Java's market share is not larger than C#

https://stackify.com/popular-programming-languages-2018/

If it was, those languages would be showing up on Github's survey above C# as well, they all consider Java independently not as a combination of all JVM languages.

-

You've contorted this conversation so ridiculously out of shape then beating the horse you laid on it.

My original comment was a rebuttal to this comment:

> While Java's slow and cautious evolution frustrates developers, it still arguably demonstrates longer-term thinking than the constant accrual of features in its contemporaries such as JavaScript and C#.

If you read the whole comment, it was not about the JVM, it was not about confusing this issue with "oh yeah well the language sucks but that's so you can run Python on it's runtime".

No idea why you are so insistent on making it about anything but the actual language called Java, not Clojure or Kotlin or Js or Python.

Because Java is both the name of a platform and the name of a language for that platform, and from its original design, the platform has been the main focus. Clojure, Kotlin and the Java language are all Java platform languages. And you'll just have to come to terms with the objective fact that other developers might disagree with your subjective language preferences. In fact, statistics would suggest that most of them would (as they would with any of us; I don't think a majority of developers would agree with any single language preference ranking). Developers know that most other developers disagree with them over language preference. That's why I'd rather speak of the platform than the language. Clearly we have different language preferences -- as most developers do -- and there is no right and wrong there.
Ugh, no Java is not the same the Java Virtual Machine, no one calls them by the same name, no one is confusing those but you.

When Github says your project has Java they don't mean your project has Clojure or JRuby.

When Tiobe says Java has X market share they don't mean JVM does.

They are not Java platform languages, they are JVM platform languages.

If you can't even talk about this using simple base definitions of the two languages that I've literally never seen argued against until today, it only compounds why I said having this conversation with you is not worth my time.

As I said, I work on OpenJDK, and the JVM constitutes less than 25% of the Java platform software (JDK). The Java language constitutes about 2% of the codebase, and Kotlin and Clojure make use of over 95% of it. They use the JVM, the Java core libraries (thanks to erased generics), and the selection of Java's debugging, profiling and monitoring tools that make up the JDK (not to mention their extensive use of third-party Java ecosystem libraries that aren't a part of the core platform). They are most definitely Java platform languages (although they're not only Java platform languages; e.g. Kotlin is also an Android language), even if colloquially many refer to the platform as "the JVM" although the JVM is only a small, yet obviously very important, part of it. Java is the name of both a programming language and the platform it is part of, and sometimes, for the sake of brevity, I too would refer to the platform as "the JVM." But as someone working on Java (not so much the language, but the platform), I try to use the more precise, more correct terminology, and I guess I'll just have to try and live with your dismay.
So when are we getting F# designers in Visual Studio?
Are you confusing IDE support with language support on a given runtime?
If you want me to talk about language support on a given runtime instead, try to use F# on .NET Native, or VB.NET on Blazor.
.NET Native is a separate compiler and runtime than the one being discussed afaik

And Blazor is part of a web framework that doesn't support VB.Net, not the underlying runtime.

Except all those runtimes are supposed to run the same MSIL.

Or if you prefer a more recent example, .NET Core only supports C++ on Windows.