Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Road to Valhalla

cr.openjdk.java.net

Post reply on HN
Print view View original

41–50 of 82 posts

Re: The Road to Valhalla

#41

Post by pas »

pjmlp wrote: post #37
BoorishBears wrote: post #30

Earlier quoted context omitted.

>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 l…

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.

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.

Re: The Road to Valhalla

#42

Post by pron »

BoorishBears wrote: post #30
pron wrote: post #25

Earlier quoted context omitted.

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, a…

>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 l…

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.

Re: The Road to Valhalla

#43

Post by pjmlp »

pas wrote: post #41
pjmlp wrote: post #37

Earlier quoted context omitted.

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.

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 w…

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.

Re: The Road to Valhalla

#44

Post by pas »

billfruit wrote: post #28
ljackman wrote: post #12

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#. That isn't to say the designers of JavaScript and C# don't think carefully about the addition of new features; indeed, was it Anders Heljsberg who made the point about all new proposed features starting with negative…

While that is interesting to hear, is there a single book that brings someone who hasn't used Java in the last 5 years upto speed, like the book Bjarne Stroustroup's 'A tour of c++' does for c++.

Book? Basically a few presentations from previous years of Java conferences is all you need.

But even faster is just looking through the release notes for the major versions.

https://en.m.wikipedia.org/wiki/Java_version_history

Re: The Road to Valhalla

#45

Post by humanrebar »

choppaface wrote: post #38
ljackman wrote: post #12

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#. That isn't to say the designers of JavaScript and C# don't think carefully about the addition of new features; indeed, was it Anders Heljsberg who made the point about all new proposed features starting with negative…

It’s interesting to look at this celebratory narrative and the fact that Valhalla took over 5 years (!?). And contrast with the rise of go and AWS Lambda. And C++, where the polished parts of boost got added to the language behind some flags (so the old language was preserved). And the growth of C++ despite the complete absence of a competitive, platform agnostic packaging & distribution solution. Wait, why do we car…

> ...complete absence of a competitive, platform agnostic packaging & distribution solution

Well, to be fair, it's more like there are two (or so) good cross platform ones at the moment, but there isn't one so popular to be de facto. And there isn't one that is standard.

Besides, the most popular packaging and distribution systems for native code might still be the popular Linux distros. Packaging and distributing precompiled binaries with native ABIs (not targeting interpreters or runtimes) is much more complicated. Folks have decided to value other things than portability of packages for now. That could change in the future.

Re: The Road to Valhalla

#46

Post by pron »

BoorishBears wrote: post #19
ljackman wrote: post #17

Earlier quoted context omitted.

These C# issues arguably demonstrate haphazard additions that didn't align with good taste: * Too many overlapping concepts for referring to code by value and defining them inline: events, delegates, anonymous delegates, and lambdas. * Lambdas that generate magic types rather than slotting into SAM types. This works great for functional languages, sure, but doesn't fit well into a class-based OOP language. * `ref` an…

I disagree with so many points in your list I don't even know if it's productive to start listing them. From implying that C# lambdas are not infinitely more useful, powerful, and intuitive than "functional interfaces" To the issues implying Properties are bad compared to the completely and utterly ridiculous situation in Java (which is exactly how they're implemented in Kotlin by the way). And your "critique" of "dy…

> 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`. All three are very minor concerns, and the last is possibly even an antipattern.

Re: The Road to Valhalla

#47

Post by ljackman »

BoorishBears wrote: post #19
ljackman wrote: post #17

Earlier quoted context omitted.

These C# issues arguably demonstrate haphazard additions that didn't align with good taste: * Too many overlapping concepts for referring to code by value and defining them inline: events, delegates, anonymous delegates, and lambdas. * Lambdas that generate magic types rather than slotting into SAM types. This works great for functional languages, sure, but doesn't fit well into a class-based OOP language. * `ref` an…

I disagree with so many points in your list I don't even know if it's productive to start listing them. From implying that C# lambdas are not infinitely more useful, powerful, and intuitive than "functional interfaces" To the issues implying Properties are bad compared to the completely and utterly ridiculous situation in Java (which is exactly how they're implemented in Kotlin by the way). And your "critique" of "dy…

FWIW, I could have produced an equally-long list of Java flaws. I'm not terribly attached to either language. I just wanted to challenge the meme that "C# is a better Java" I hear on the Internet every other week.

"Infinitely" more useful seems like a stretch. Both languages made valid design decisions with their lambdas: autogenerated types means not every variant of lambda needs a backing interface, but it also means that the types are a world unto themselves and not integrated with well-established interfaces and abstract classes in the way that Java lambdas are, resulting in conflicting mechanisms for passing code to adhere to a requirement. I find the unification of SAM types and lambdas to be elegant in a class-based OOP language (and actually preferable to the Smalltalk/Ruby block model too), but it's clearly subjective.

My criticism of properties hiding side-effects as attribute reads is mostly derived from one of the earliest books about the CLR; was it "The CLR via C#"? I'll have to check. The critique isn't Java-inspired; getters have the same problem of course. The point is that a getter is a method call, so you expect potential side-effects. You don't expect side-effects from a property read, although C# does tend to use capital letters for properties, to be fair.

While on the topic of CLR, I realise the DLR exposed dynamic typing primarily to make the CLR a better target for dynamic languages; I was arguing that exposing that up to C# wasn't necessary. C# is the flagship CLR language, sure, but that doesn't mean it must expose _every_ feature of it. Java also added `invokedynamic` for similar reasons but didn't feel the need to expose it to its flagship language directly in language syntax.

pron covered the nuances around generic type erasure in another comment better than I did, so I won't reiterate. Like you, I still mildly prefer reified generics over erasure as a language user, but the points raised by pron and Bracha are absolutely real. The ability to do runtime type checks and default values on generics seem like antipatterns, so I'm glad Java doesn't support those _specific_ features of reification even if I like a lot of the others parts.

Re: The Road to Valhalla

#48

Post by ljackman »

jayd16 wrote: post #35
ljackman wrote: post #17

Earlier quoted context omitted.

These C# issues arguably demonstrate haphazard additions that didn't align with good taste: * Too many overlapping concepts for referring to code by value and defining them inline: events, delegates, anonymous delegates, and lambdas. * Lambdas that generate magic types rather than slotting into SAM types. This works great for functional languages, sure, but doesn't fit well into a class-based OOP language. * `ref` an…

This mostly reads to me as a list of things I miss when I go back to Java.

Fair enough; I do miss keyword and default arguments from C# when using Java. A long list of overloads and argument forwarding to fake default arguments gets old.

Re: The Road to Valhalla

#49

Post by ljackman »

phillipcarter wrote: post #33
ljackman wrote: post #17

Earlier quoted context omitted.

These C# issues arguably demonstrate haphazard additions that didn't align with good taste: * Too many overlapping concepts for referring to code by value and defining them inline: events, delegates, anonymous delegates, and lambdas. * Lambdas that generate magic types rather than slotting into SAM types. This works great for functional languages, sure, but doesn't fit well into a class-based OOP language. * `ref` an…

> Nullable reference types. Getting rid of null is good, but this proposal became confusing. They mentioned opting in assembly-wide for a while but there was then a conversation about having it just warn in some cases. I need to read the latest literature around this, but it seemed less elegant than Java just adding a monad-like Optional type and not adding loads of special-case operations with question marks everywh…

Thanks for the clarification on the final NRT behaviour. Just to say, my point about "didn't align with good taste" was itself lacking taste. I'm sure each of those features I critiqued made sense as they were proposed at the time and were just considering different use cases and tradeoffs.

Did it drop the idea of assembly-wide opt-ins to stricter behaviour, meaning all NRTs can be reasoned about in the same way without considering a configuration flag somewhere like PHP? That does sound like an improvement.

Doing the change gradually, without breaking existing code or requiring potentially-ecosystem-breaking opt-ins does seem eminantly sensible and user-friendly. I was being too harsh to C# here. Java's `Optional` doesn't even warn about it itself being null, for example. You need static tooling and code analysis for that. C#'s solution does at least try to solve that, albeit at the cost of more complexity.

I said "monad-like" rather than "monadic" for that reason, but arguably it doesn't even go far enough to be considered monadic-like. Certainly this article would agree: https://blog.developer.atlassian.com/optional-broken/

Re: The Road to Valhalla

#50

Post by adimitrov »

raiflip wrote: post #16

Tangentially related questions to generics, anyone think java will ever get higher kinded types? It would be super useful to have a better way of expressing higher level abstractions.

Java will not get HKTs in yours and my lifetime. What might get HKTs is Kotlin. There's a proposal brought forward by the Arrow people that has attracted a lot of attention.

https://github.com/Kotlin/KEEP/pull/87

If if that does not succeed, the Arrow folks are working on a meta compiler (think template Haskell but with IDE support) that should get you HKTs and union types.

https://github.com/arrow-kt/arrow-meta

Regardless, something quite close to HKTs is available today via type level defunctionalisation. Just look at the Arrow docs

Post reply on HN