5 ms·
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 v
by pron 5y ago
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.
- bberrry 5y agoText blocks?
- pron 5y agoHmm, I think Kotlin's are similar to Python's, but Java's are different (whitespace handling).
- _old_dude_ 5y ago> 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 https://dotty.epfl.ch/docs/reference/enums/adts.html
- pron 5y agoJava 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.
- _old_dude_ 5y agoOk, 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.
- pron 5y ago> 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.
- _old_dude_ 5y agoPattern 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.
- RhodesianHunter 5y agoWhat 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.
- kaba0 5y agoYou 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.
- RhodesianHunter 5y agoOf course none of this is new, but the lead time from Kotlin adoption to Java adoption of all of them is near identical.
- kaba0 5y agoThat’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.
- RhodesianHunter 5y agoYou 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.