Live data from Hacker News

Java is becoming more like Rust, and I am here for it

joshaustin.tech

21–30 of 71 posts

Re: Java is becoming more like Rust, and I am here for it

#21
I am here for it too. Java's release cycle is now 6 months (matching Go's), and Java is introducing more of the features that make the 'newer' languages pleasant to use. Features like Pattern Matching for switch[1], Virtual threads [2], and String templates[3]

[1] https://openjdk.org/jeps/441 [2] https://openjdk.org/jeps/444 [3] https://openjdk.org/jeps/430

Re: Java is becoming more like Rust, and I am here for it

#22
post #3

The article is using immutable records and sum types as “more like Rust” and I am just sitting in the corner, wondering whether everyone has forgotten that these things came from FP in the first place. In my mind, a language isn’t “Rust-like” because it uses concepts we learned in FP. We have languages like Haskell and, before it, ML. And I know ML didn’t invent it. We also have Scala, and for Scala, we don’t even ha…

The Java stuff is definitely coming from FP and not Rust at all.

Re: Java is becoming more like Rust, and I am here for it

#23

It's consistently been impressive to me how thoughtful the Java language is being steered. Especially the explicit choice to NOT have an async keyword where other languages were all falling over themselves to add it, with all the complexity it entails (and in Rust it's a pretty awkward fit). Once projects Valhalla and Panama land Java will be transformed again. Exciting times.

I think async worked out pretty well with JavaScript. But that was added to an already async language, it was just verbose and awkward before the await keyword.

In what way was the language async? It has no threads outside workers, which have strict limits regarding data sharing. You would see a lot of code that registers callbacks as event handlers, but I don't think that makes the language async. That's just the nature of event handlers. They are invoked later, when the event happens.

In a way, the lack of threading allowed `async` to be implemented without gotchas. In languages with first-class thread support, `async` implementations can run into thread issues. (Will the continuation run on the same thread? Does the code care?)

Re: Java is becoming more like Rust, and I am here for it

#27
post #3

The article is using immutable records and sum types as “more like Rust” and I am just sitting in the corner, wondering whether everyone has forgotten that these things came from FP in the first place. In my mind, a language isn’t “Rust-like” because it uses concepts we learned in FP. We have languages like Haskell and, before it, ML. And I know ML didn’t invent it. We also have Scala, and for Scala, we don’t even ha…

Isn't F# more like a nephew of OCaml and cousin of C#?

F# "originated as an OCaml implementation", which runs on .NET with some C# interop support?

Re: Java is becoming more like Rust, and I am here for it

#28

I think a better description is "Java is becoming more like C#", which got these immutable-by-default record types many years ago.

C# still, to my regret, doesn't have anything like sealed interfaces. The closest thing I've found is an abstract class with an `internal` constructor. That prevents sub-classing from outside the compilation unit, but it still doesn't exactly capture the intent.

Re: Java is becoming more like Rust, and I am here for it

#29
post #19

[flagged]

The modern belief is that [] should be reserved for generics[0]. In fairness, I've never seen a language actually stick to that and that's also a bit hollow when Java itself uses for generics in the first place.

[0]https://soc.me/languages/stop-using-angle-brackets-for-gener...

Re: Java is becoming more like Rust, and I am here for it

#30
post #11

I imagine the lineage here is more Scala than Rust, right? Not that Scala invented these concepts, but if you’re looking for proven features with JVM implementations to add to Java, you’re probably going to look to Scala (and Kotlin) first.

The OpenJdk team has said multiple times that their inspirations are coming from ML and not Scala or Kotlin.

I’m sure that’s true to an extent, but calling your sum types “sealed” is pretty explicitly borrowing from Scala. Which is fine. I think it’s good that they’re pulling inspiration from a bunch of different places.
Post reply on HN