Hacker News Reader

Comment by pron | Hacker News Reader

Java has not picked up a single feature from Kotlin yet (maybe nullability types someday?), and, in fact, opted for very different ones (e.g. contrast records vs. data classes, virtual threads vs. syntactic couroutines), although I guess Scala has provided some inspiration for some features, as Java's are closer to Scala's than to Kotlin's. ML is probably the biggest influence, with some Haskell flavour. But I find it amusing that people think that Java is trying to compete with other languages on the Java platform, no matter how small, rather than with bigger, more relevant competitors.

View on HN

> ML is probably the biggest influence

I disagree.

Java records are from Standard ML but sealed is not, it's from Scala with the improvement that subtypes of a sealed types are sealed too.

Java still not have a real syntax for ADT, Standard ML has datatype, Rust or Scala 3 have enums on steroid [1].

[1] https://dotty.epfl.ch/docs/reference/enums/adts.html

Java records and sealed types are its interpretation of product and sum types, and, true, this interpretation draws inspiration from Scala's. Deconstructing patterns are coming soon, but Java now does have real syntax for ADTs:

    sealed interface Expr {}
    record ConstantExpr(int i)       implements Expr {}
    record PlusExpr(Expr a, Expr b)  implements Expr {}
    record TimesExpr(Expr a, Expr b) implements Expr {}
    record NegExpr(Expr e)           implements Expr {}

For non-record classes, deconstructing patterns will be something like a dual to methods, and almost a first-class citizen. Among other things, they will allow patterns to support API designs that predate records and sealed types.

Ok, it's perhaps a true Scotsman argument but saying that Java as a syntax for ADT is like saying JS (pre 2015) has classes because it can be simulated by function + prototype or that Java (pre 8) has lambdas because it can be simulated by anonymous classes.

Java misses the syntactic sugar to define ADT in one place like in Standard ML, OCaml or F#.

The closest you get is to declare records inside a sealed interface, but once you add generics in the mix, it starts to get messy.

I was not able to define a classical list with cons and nil in Java.

  sealed interface List<T> {
    record Cons<T>(T car, List<T> cdr) implements List<T> {}
    record Nil() implements List {} 
  }

The compiler give you warnings, Cons<T> or Nil are not a top level type and you can create several instances of Nil.

> Java misses the syntactic sugar to define ADT in one place like in Standard ML, OCaml or F#.

I don't think so.

> I was not able to define a classical list with cons and nil in Java.

If you want to restrict Nil to a single instance, don't make it a record class:

    sealed interface List<T> {
      static <T> List<T> cons(T car, List<? extends T> cdr) { return new Cons<T>(car, cdr); }
      static <T> List<T> nil() { return (List<T>)Nil.INSTANCE; }

      record Cons<T>(T car, List<? extends T> cdr) implements List<T> {}
      enum   Nil implements List<Void> { INSTANCE }
    }

You can statically import if you mind them not being "top level":

    import static List.*;

And then write, say:

    var x = cons("a", nil());
    var y = cons(1, x);

Not as succinct as ML, but workable.

Although, in this particular case,

    record List<T>(T car, List<? extends T> cdr){}

would suffice.

Pattern matching does not work if you use an enum

  List<String> list = cons("a", nil());
  switch(list) {
    case Cons<String>(var car, var cdr) -> ...
    case Nil -> ...
  }

Nil is typed List<Void> which is not compatible with List<String>.

You may be able to use extractors as the inverse of the static methods cons() and nil() but that adds more boilerplate.

Disjunctive enums like in Rust or Scala 3 is a simpler way to define ADT.

Pattern matching will work fine with an additional explicit nil() pattern. I agree that in this particular case it's not quite as succinct as in more functional languages, but virtually all cases in ordinary business applications are not like that, and the additional code, if any, is O(1).

Of course, Java could add rules for the special case of zero-argument records, making them more enum-like, but I really think the value in doing that is negative. Other than being able to directly translate ML examples, it would add complexity that isn't worth it.

In fact, in this particular case I'd do it like so:

    record List<T>(T car, List<? extends T> cdr) {
      public List { if (car == null) throw new IllegalArgumentException("null element"); } 
    }

Which would give you:

    switch(list) {
      case List<String>(var car, var cdr) -> ...
      case null -> ...
    }

It might not be exactly what people who like Scala might prefer, but it is very much a good representation of ADTs for those who prefer Java.

Text blocks?

Hmm, I think Kotlin's are similar to Python's, but Java's are different (whitespace handling).

What are you talking about? Java release notes look like a list of Kotlin features these days.

Sealed classes, data classes, multiline strings, coroutines -> project loom, switch statement improvements to resemble Kotlin when statement, improvements to Streams to match Sequences.

You do realize there are plenty of languages out there, and most novel features appeared first in some minor research languages? Like, there is hardly anything original to kotlin on your list, sealed classes have been in scala forever, and are basically just algebraic data types. Data classes are.. data classes, multiline strings is a cool but very basic syntactic sugar available in millions of languages, coroutines have been around, and kotlin’s couroutines are nothing like project loom. The latter is more similar to go’s threads. Switch expressions have been in scala forever, but a pretty basic thing in FP languages.

Of course none of this is new, but the lead time from Kotlin adoption to Java adoption of all of them is near identical.

That’s irrelevant. It’s not like the language team didn’t know about these features. The change to the shorter release cycle and increased funding is much more behind the speed up of updates regarding Java.

You keep claiming that the language team's knowledge of a feature drives that feature's adoption.

That's not accurate.

Popularity of a feature and enterprise demand drive it's adoption.

It doesn't really matter what the language team knows, it matters what the average developer knows since their collective wants are in large part what drives the language team.

There are hundreds of thousands of Java devs who only ever wrote Java and suddenly had to write Kotlin, and are now clambering for these feature improvements in Java.

I would agree with you, Java routinely uses the "last-mover's advantage" tactic, but I think you overestimate the relative sizes of the two languages. These are all very basic FP "features"/language primitives, and Java is steering strongly towards becoming an ML-inspired FP-enhanced language.

If anything, the acceptance of more parts of the FP paradigm into all major languages (like C#, JS/TS, C++) starting with lambdas likely have pushed Java, but to single out the all-around very niche Kotlin language as a source is imo a non sequitur.

There are almost 3 billion Android devices. I think you underestimate the scope of the primary language on one of the world's most prolific OS's.

There aren't as many mobile developers as you'd think: https://www.hiringlab.org/2019/11/19/todays-top-tech-skills/

That article is from 2019 and only focuses on languages. At that time most of the Android jobs would be hopelessly intertwined with the Java jobs.

It's also important to not be US centric. In many parts of the world Android is the dominant OS.

1. That's not really right. You're correct that "readiness" is important, but Python and JS are much bigger forces than Kotlin, and the main reason Java is getting features faster is because the investment in the platform has grown (and Kotlin was created when it was at an ebb). But so far, almost all linguistic features added after 1.0 -- generics, lambdas, type inference, ADTs, patterns -- are inspired by ML.

2. Java addresses those topics (where relevant) pretty much in the opposite way from Kotlin. Java rejected coroutines and is going down a completely different path with virtual threads; Java rejected data classes and chose to go down algebraic data types. So if you think Java gets inspiration from Kotlin, then it is in the form of what not to do.

These aren’t ‘Kotlin features’ they’re just normal language features.

I really struggle to see Kotlin as being part of the debate here. These features are being driven by enterprise Java user pain points. And those people aren’t looking at Kotlin.

I agree that this would probably happen in the Java world, regardless of kotlin. However, I disagree with the statement that enterprise Java users are not looking at kotlin. From my view (in a large, global consulting business), we see large enterprise Java users adopting kotlin.

>These features are being driven by enterprise Java user pain points

By Java devs who only ever wrote Java, and suddenly had to write Kotlin for Android. They're now aware of these features as a result and are demanding them in Java.

Reply on news.ycombinator.com