4 ms·

Kotlin provides modern features in the Android development Java land stuck on the ancient Java 6. Scala was an academic experiment on how to match nicely objec

Kotlin provides modern features in the Android development Java land stuck on the ancient Java 6. Scala was an academic experiment on how to match nicely object oriented world with functional programing paradigm that got some hype because Java development was crawling like a snail. I am not sure if this experiment was successful after all, though.

kllrnohj 3y ago
Android isn't stuck on Java 6 and many of the changes are in the compiler not the runtime anyway.
- saagarjha 3y ago
  It’s basically stuck there unless you go look up a list of caveats of what has been selectively implemented.
  - re-thc 3y ago
    And then you have to consider devices you want to support.
spockz 3y ago
With Scala 3 a lot of the idiosyncrasies of scala 1/2 got fixed. (If you can get over some naming.) What is mostly brings for me is showing that composition beats inheritance and that classic OO trying to shove the real world in an inheritance tree is not the way to go. Also, it got Java to move up development, together with the move to cloudnative. From a language enthousiast point of view I’m still curious why Kotlin and now these features in Java get so much traction while most have been available for 20 years in Scala. Was it marketing? Was it people? Was it symbol soup? Who knows?
- vbezhenar 3y ago
  As a Java developer for 15 years and as a language enthusiast myself I'm curious as well. Because I definitely don't see many places where I would use pattern matching in my code or even records. Recently I wrote like 10k LoC and I used record once: in test code to return pair of values. May be I'll replace some `if`-s with pattern matching, just like I use `instanceof` pattern matching today, but that's absolutely minor thing which is hardly worth mentioning. I would even dare to say that lambdas and `var`-s for me are questionable features. Actually as I grow older, I appreciate ascetic nature of Go and sometimes I think that using Java 1.4 might actually be preferable for many codebases. I understand that for code which manipulates trees like compilers with their ASTs, pattern matching might be god send. The thing is... 99.99% of developers don't write this code, so optimizing language for it is strange goal. Sometimes I think that some language features are driven by hype, even with Java. I always happy about runtime improvements, though. And Java delivers in that front, so I can tolerate pattern matching and streams if I can get virtual threads and struct values.
  - soulbadguy 3y ago
    > Because I definitely don't see many places where I would use pattern matching in my code or even records. Recently I wrote like 10k LoC and I used record once: in test code to return pair of values. Without knowing your application domain or seeing the code, it's hard to guess why. But one reason is that pattern matching and union/algebraic type tend to go hands to hands. So depending on how your data domain was modeled, it is normal that you don't find yourself not needing to pattern match as much. In general,it's normal to find one self "not needing" a feature that one is not used to, professional are very good at structuring things is a way that work best with the current toolings. > I understand that for code which manipulates trees like compilers with their ASTs, pattern matching might be god send Very true, but i can assure you , pattern matching (combined with record and ADT) are very useful tools in general computation as well.
  - haspok 3y ago
    As they say, "the determined Real Programmer can write FORTRAN programs in any language.". ADTs and pattern matching go hand in hand, and they - along with immutable structures - are the cornerstones of functional programming. They provide you very strong compile-time guarantees in a very elegant and readable form. I like to write code this way, and out of 10k LoC I would estimate at least half is ADTs and pattern matching for me. Maybe more. Too bad that although Java's ADTs are coming along nicely, pattern matching is in it's infancy (due to limitations inherent in Java). This is the single language feature I miss the most from Java and Kotlin from Scala.
- zdragnar 3y ago
  As someone who is only tangentially familiar with jvm functional languages and hasn't written java in years, "symbol soup" almost certainly has a lot of the blame. Java is simple. There were few operators, and really only one way to call a function. All function calls require parentheses. Conventions are available for pretty much any problem you can think of. In functional land, you don't need to bother with calling a function a factory, or adapter, or whatever overwrought GoF pattern was maladapted. Despite being verbose and convoluted, Java was all basically the same things- classes and methods and a few annotations, and easy to Google concepts. Enter symbol soup. Now, your conventions aren't named, you have to recognize them from experience. That creates writer's anxiety- even if I understand what I am reading, if I need to start from scratch I don't know that I'm organizing things right. There are multiple symbols that apply, combine or call functions, googling symbols is hard, asking questions is hard in meat space without a screen to show the unfamiliar syntax, and that's all table stakes before you get into understanding performance implications, code organization, maintainability, etc. If I, hypothetical developer, don't know these things and don't have someone to hold my hand, but I DO know java, what's the point of learning the functional language? This is the same problem F# had. Over time, C# kept getting all the good bits from F# without the baggage. Java has taken the longer road to get there, but today, if I were to pick one, the value proposition of the functional language appears to be on a trajectory of disappearing.
  - macintux 3y ago
    The problem I always have with OO (or imperative) languages picking up functional features is that the constraints of functional languages are, to me, among the biggest wins. When I know that any library I invoke is literally incapable of changing the data I pass to it, that's tremendously freeing.
- deleted 3y ago
  [deleted]
wasyl 3y ago
> Kotlin provides modern features in the Android development Java land stuck on the ancient Java 6. These days you can use Java 8 features with no issues, and Kotlin isn't really solving the fundamental problem of runtime version on target devices — it's just spitting out Java 8 bytecode by default. Android build system already _desugars_ newer Java language features for older runtimes, and they could do the same thing for all the new fancy features. I guess they choose not to because Kotlin is already there. That said, I do believe Kotlin is still more concise, has better nullability handling, and upcoming exciting features of its own like compiler plugins
pjmlp 3y ago
Google has been forced to update to Java 11 LTS and Android 14 brings Android 17 LTS. It turns out that Kotlin being able to consume Java libraries is worthless if Android can only use jurassic libraries.
grishka 3y ago
It is a common misconception. I use Java 17 on Android just fine. The only limitation is that you can't use features that rely on methods and classes introduced after Java 11, for example records. For bridging the gap between 6 and 11 Google provides a "desugaring" library.
- WirelessGigabit 3y ago
  So records in Java aren't syntactic sugar over an immutable class? They appear in Bytecode?
  - grishka 3y ago
    I'm not sure how they appear in bytecode but they extend java.lang.Record under the hood, which is a new class that the desugaring library doesn't have. Switch expressions and all the pattern-matching stuff though — that's all implemented entirely in the compiler. I use it on Android quite extensively with no issues.

kllrnohj 3y ago

Android isn't stuck on Java 6 and many of the changes are in the compiler not the runtime anyway.

saagarjha 3y ago
It’s basically stuck there unless you go look up a list of caveats of what has been selectively implemented.
- re-thc 3y ago
  And then you have to consider devices you want to support.

spockz 3y ago

With Scala 3 a lot of the idiosyncrasies of scala 1/2 got fixed. (If you can get over some naming.) What is mostly brings for me is showing that composition beats inheritance and that classic OO trying to shove the real world in an inheritance tree is not the way to go. Also, it got Java to move up development, together with the move to cloudnative. From a language enthousiast point of view I’m still curious why Kotlin and now these features in Java get so much traction while most have been available for 20 years in Scala. Was it marketing? Was it people? Was it symbol soup? Who knows?

vbezhenar 3y ago
As a Java developer for 15 years and as a language enthusiast myself I'm curious as well. Because I definitely don't see many places where I would use pattern matching in my code or even records. Recently I wrote like 10k LoC and I used record once: in test code to return pair of values. May be I'll replace some `if`-s with pattern matching, just like I use `instanceof` pattern matching today, but that's absolutely minor thing which is hardly worth mentioning. I would even dare to say that lambdas and `var`-s for me are questionable features. Actually as I grow older, I appreciate ascetic nature of Go and sometimes I think that using Java 1.4 might actually be preferable for many codebases. I understand that for code which manipulates trees like compilers with their ASTs, pattern matching might be god send. The thing is... 99.99% of developers don't write this code, so optimizing language for it is strange goal. Sometimes I think that some language features are driven by hype, even with Java. I always happy about runtime improvements, though. And Java delivers in that front, so I can tolerate pattern matching and streams if I can get virtual threads and struct values.
- soulbadguy 3y ago
  > Because I definitely don't see many places where I would use pattern matching in my code or even records. Recently I wrote like 10k LoC and I used record once: in test code to return pair of values. Without knowing your application domain or seeing the code, it's hard to guess why. But one reason is that pattern matching and union/algebraic type tend to go hands to hands. So depending on how your data domain was modeled, it is normal that you don't find yourself not needing to pattern match as much. In general,it's normal to find one self "not needing" a feature that one is not used to, professional are very good at structuring things is a way that work best with the current toolings. > I understand that for code which manipulates trees like compilers with their ASTs, pattern matching might be god send Very true, but i can assure you , pattern matching (combined with record and ADT) are very useful tools in general computation as well.
- haspok 3y ago
  As they say, "the determined Real Programmer can write FORTRAN programs in any language.". ADTs and pattern matching go hand in hand, and they - along with immutable structures - are the cornerstones of functional programming. They provide you very strong compile-time guarantees in a very elegant and readable form. I like to write code this way, and out of 10k LoC I would estimate at least half is ADTs and pattern matching for me. Maybe more. Too bad that although Java's ADTs are coming along nicely, pattern matching is in it's infancy (due to limitations inherent in Java). This is the single language feature I miss the most from Java and Kotlin from Scala.
zdragnar 3y ago
As someone who is only tangentially familiar with jvm functional languages and hasn't written java in years, "symbol soup" almost certainly has a lot of the blame. Java is simple. There were few operators, and really only one way to call a function. All function calls require parentheses. Conventions are available for pretty much any problem you can think of. In functional land, you don't need to bother with calling a function a factory, or adapter, or whatever overwrought GoF pattern was maladapted. Despite being verbose and convoluted, Java was all basically the same things- classes and methods and a few annotations, and easy to Google concepts. Enter symbol soup. Now, your conventions aren't named, you have to recognize them from experience. That creates writer's anxiety- even if I understand what I am reading, if I need to start from scratch I don't know that I'm organizing things right. There are multiple symbols that apply, combine or call functions, googling symbols is hard, asking questions is hard in meat space without a screen to show the unfamiliar syntax, and that's all table stakes before you get into understanding performance implications, code organization, maintainability, etc. If I, hypothetical developer, don't know these things and don't have someone to hold my hand, but I DO know java, what's the point of learning the functional language? This is the same problem F# had. Over time, C# kept getting all the good bits from F# without the baggage. Java has taken the longer road to get there, but today, if I were to pick one, the value proposition of the functional language appears to be on a trajectory of disappearing.
- macintux 3y ago
  The problem I always have with OO (or imperative) languages picking up functional features is that the constraints of functional languages are, to me, among the biggest wins. When I know that any library I invoke is literally incapable of changing the data I pass to it, that's tremendously freeing.
deleted 3y ago
[deleted]

wasyl 3y ago

> Kotlin provides modern features in the Android development Java land stuck on the ancient Java 6. These days you can use Java 8 features with no issues, and Kotlin isn't really solving the fundamental problem of runtime version on target devices — it's just spitting out Java 8 bytecode by default. Android build system already _desugars_ newer Java language features for older runtimes, and they could do the same thing for all the new fancy features. I guess they choose not to because Kotlin is already there. That said, I do believe Kotlin is still more concise, has better nullability handling, and upcoming exciting features of its own like compiler plugins

pjmlp 3y ago

Google has been forced to update to Java 11 LTS and Android 14 brings Android 17 LTS. It turns out that Kotlin being able to consume Java libraries is worthless if Android can only use jurassic libraries.

grishka 3y ago

It is a common misconception. I use Java 17 on Android just fine. The only limitation is that you can't use features that rely on methods and classes introduced after Java 11, for example records. For bridging the gap between 6 and 11 Google provides a "desugaring" library.

WirelessGigabit 3y ago
So records in Java aren't syntactic sugar over an immutable class? They appear in Bytecode?
- grishka 3y ago
  I'm not sure how they appear in bytecode but they extend java.lang.Record under the hood, which is a new class that the desugaring library doesn't have. Switch expressions and all the pattern-matching stuff though — that's all implemented entirely in the compiler. I use it on Android quite extensively with no issues.