4 ms·

Interesting. From an outside perspective, I had the impression Java devs would migrate to Kotlin.

by k__ 5y ago

dehrmann 5y ago
Kotlin is nice, but setting up the build system can be a bit clunky, stack traces aren't quite as clear, it's more of a moving target, and important things like record classes are making it into Java. I tried it, but realized the code ended up being similar, just with less boilerplate, and switched back to Java. I feel like Scala went through a similar lifecycle. It looked amazing, supported lots of coding paradigms, but had a lousy build system. Once Java added lambdas, it was good enough, and Scala wasn't worth the hassle. Also, remember Groovy?
- k__ 5y ago
  I see. I had the impression the Java build system was rather convulted.
  - rhacker 5y ago
    It had a reputation for this in the days of ANT. However Maven (and to some degree gradle) kinda made it a non-issue.
    - pjmlp 5y ago
      Gradle is Ant for devs that never lived through Ant build hell.
    - k__ 5y ago
      I heard that years ago, but I never worked with ANT. My "convulted build system" experiences all came from Maven and Gradle.
      - Alupis 5y ago
        Then I dare say you do not know the meaning of "convoluted build system". Thousands, or tens of thousands of lines of semi-proprietary/non-standard XML is what made up ANT build scripts... mostly or entirely hand written for each and every project. Even small hobby projects had build scripts in the thousands of lines... there was no such thing as dependency management, and nothing came "for free". Every single thing had to be hand written into the script because ANT didn't have any inkling what you might want to do... build targets layered upon each other until rationalizing about what happens when during the build becomes a full time job all in it's own. Maven is amazing. With a few lines of XML you can successfully build nearly every project, manage all dependencies, etc. The trade-off? It's extremely opinionated in how your project is managed and how it's laid out. Worth while in most cases.
        k__ 5y ago
        Good point. I guess, for me, everything that is XML is just convulted legacy stuff.
        Alupis 5y ago
        I can understand, although I find modern tooling makes XML painless, at least for me.
- dangets 5y ago
  I'm sold on Kotlin and have been working professionally in it for a few years (mixed Kotlin/Java projects server-side), so take my opinion for what it's worth. Integrating with Java's existing build systems (Gradle, Maven) was one of JetBrains initial design goals to avoid the separate ecosystem requirement that initially came with Scala. I admit building Kotlin has some quirks, notably around annotation processors - but overall it is very seamless. I am happy Java is adding new stuff (records, switch expressions, sealed classes), but I worry it is increasing overall language complexity vs. the fresh start that Kotlin was able to take. Supporting the legacy patterns in the language adds to the complexity any given Java developer is supposed to know. Overall I think the sane defaults and nudges towards the right patterns Kotlin pushes are a much bigger deal than just reducing boilerplate - though that is nice too.
vips7L 5y ago
Personally I'm not sold on Kotlin. I don't think it offers much for me over Java 17. Maybe nullable types? But I haven't had problems with null in years.
- deepsun 5y ago
  It's just a syntactic sugar. E.g. allowing last functional parameter to be specified after the closing parentheses makes possible to create interesting structures that look more like config file than procedural code. But in general it's just the same Java, e.g. you would search for "how to do that in Java", not "in Kotlin".
  - NoSorryCannot 5y ago
    Kotlin has more compilation targets than Java, so I don't know that you can say that.
    - deleted 5y ago
      [deleted]
  - zorr 5y ago
    It started out that way but in my eyes it has evolved to much more than just syntactic sugar. While Kotlin closures, receiver arguments, "it", extension functions, nullability operator, var/val, "when" pattern matching, sealed classes and smartcasts are mostly implemented as syntactic sugar, combining all of the above enables some interesting programming patterns. Some examples are Compose for building reactive/functional UI and TornadoFX for declarative UI on top of JavaFX. Coroutines and suspend functions provide structured concurrency and an async paradigm that interopts well with the "old" Java CompletableFuture apis and existing libraries. Kotlin Flow is the answer for observability and rx-like reactive programming. Kotlin multiplatform (while still in early development) allows sharing code between JVM, web and native targets (even iOS) with a decent-ish build system. I'm very bullish on the future of Kotlin and have been using it for years as my goto language for backend apis, MPA's, Android and JVM desktop projects. I'm excited to expand that into some combined web/iOS/android/desktop projects in the very near future.
pjmlp 5y ago
That is like saying UNIX would migrate away from C. Kotlin got lucky with Android, Google should have all the fun with their own version of .NET.
- k__ 5y ago
  "That is like saying UNIX would migrate away from C." Isn't exactly this happening now with Rust?
  - pjmlp 5y ago
    None of the tiny OSes written in Rust are UNIX. https://www.opengroup.org/openbrand/register/ https://www.opengroup.org/openbrand/register/ Note that ISO C is part of POSIX certification.
  - deleted 5y ago
    [deleted]
  - Koshkin 5y ago
    The userland at least seems to be moving more and more towards C++.
    - deleted 5y ago
      [deleted]
    - pjmlp 5y ago
      Kind of, although C++ does have an advantage that others lack, it also shares the same symbiotic relationship with UNIX, by having been born on the same place as UNIX and C, by the same group of people of Bell Labs employees and initially started as C pre-processor. Which is also a reason why it cannot get rid of the flaws it inherited from such relationship.
bcrosby95 5y ago
As a long time Java dev, if I could pick a language to migrate to it would be Clojure, Erlang, Elixir, or Golang. In roughly that order.

Interesting. From an outside perspective, I had the impression Java devs would migrate to Kotlin.

by k__ 5y ago

Interesting. From an outside perspective, I had the impression Java devs would migrate to Kotlin.

Kotlin is nice, but setting up the build system can be a bit clunky, stack traces aren't quite as clear, it's more of a moving target, and important things like record classes are making it into Java. I tried it, but realized the code ended up being similar, just with less boilerplate, and switched back to Java. I feel like Scala went through a similar lifecycle. It looked amazing, supported lots of coding paradigms, but had a lousy build system. Once Java added lambdas, it was good enough, and Scala wasn't worth the hassle. Also, remember Groovy?

k__ 5y ago
I see. I had the impression the Java build system was rather convulted.
- rhacker 5y ago
  It had a reputation for this in the days of ANT. However Maven (and to some degree gradle) kinda made it a non-issue.
  - pjmlp 5y ago
    Gradle is Ant for devs that never lived through Ant build hell.
  - k__ 5y ago
    I heard that years ago, but I never worked with ANT. My "convulted build system" experiences all came from Maven and Gradle.
    - Alupis 5y ago
      Then I dare say you do not know the meaning of "convoluted build system". Thousands, or tens of thousands of lines of semi-proprietary/non-standard XML is what made up ANT build scripts... mostly or entirely hand written for each and every project. Even small hobby projects had build scripts in the thousands of lines... there was no such thing as dependency management, and nothing came "for free". Every single thing had to be hand written into the script because ANT didn't have any inkling what you might want to do... build targets layered upon each other until rationalizing about what happens when during the build becomes a full time job all in it's own. Maven is amazing. With a few lines of XML you can successfully build nearly every project, manage all dependencies, etc. The trade-off? It's extremely opinionated in how your project is managed and how it's laid out. Worth while in most cases.
      - k__ 5y ago
        Good point. I guess, for me, everything that is XML is just convulted legacy stuff.
        Alupis 5y ago
        I can understand, although I find modern tooling makes XML painless, at least for me.
dangets 5y ago
I'm sold on Kotlin and have been working professionally in it for a few years (mixed Kotlin/Java projects server-side), so take my opinion for what it's worth. Integrating with Java's existing build systems (Gradle, Maven) was one of JetBrains initial design goals to avoid the separate ecosystem requirement that initially came with Scala. I admit building Kotlin has some quirks, notably around annotation processors - but overall it is very seamless. I am happy Java is adding new stuff (records, switch expressions, sealed classes), but I worry it is increasing overall language complexity vs. the fresh start that Kotlin was able to take. Supporting the legacy patterns in the language adds to the complexity any given Java developer is supposed to know. Overall I think the sane defaults and nudges towards the right patterns Kotlin pushes are a much bigger deal than just reducing boilerplate - though that is nice too.

vips7L 5y ago

Personally I'm not sold on Kotlin. I don't think it offers much for me over Java 17. Maybe nullable types? But I haven't had problems with null in years.

deepsun 5y ago
It's just a syntactic sugar. E.g. allowing last functional parameter to be specified after the closing parentheses makes possible to create interesting structures that look more like config file than procedural code. But in general it's just the same Java, e.g. you would search for "how to do that in Java", not "in Kotlin".
- NoSorryCannot 5y ago
  Kotlin has more compilation targets than Java, so I don't know that you can say that.
  - deleted 5y ago
    [deleted]
- zorr 5y ago
  It started out that way but in my eyes it has evolved to much more than just syntactic sugar. While Kotlin closures, receiver arguments, "it", extension functions, nullability operator, var/val, "when" pattern matching, sealed classes and smartcasts are mostly implemented as syntactic sugar, combining all of the above enables some interesting programming patterns. Some examples are Compose for building reactive/functional UI and TornadoFX for declarative UI on top of JavaFX. Coroutines and suspend functions provide structured concurrency and an async paradigm that interopts well with the "old" Java CompletableFuture apis and existing libraries. Kotlin Flow is the answer for observability and rx-like reactive programming. Kotlin multiplatform (while still in early development) allows sharing code between JVM, web and native targets (even iOS) with a decent-ish build system. I'm very bullish on the future of Kotlin and have been using it for years as my goto language for backend apis, MPA's, Android and JVM desktop projects. I'm excited to expand that into some combined web/iOS/android/desktop projects in the very near future.

pjmlp 5y ago

That is like saying UNIX would migrate away from C. Kotlin got lucky with Android, Google should have all the fun with their own version of .NET.

k__ 5y ago
"That is like saying UNIX would migrate away from C." Isn't exactly this happening now with Rust?
- pjmlp 5y ago
  None of the tiny OSes written in Rust are UNIX. https://www.opengroup.org/openbrand/register/ https://www.opengroup.org/openbrand/register/ Note that ISO C is part of POSIX certification.
- deleted 5y ago
  [deleted]
- Koshkin 5y ago
  The userland at least seems to be moving more and more towards C++.
  - deleted 5y ago
    [deleted]
  - pjmlp 5y ago
    Kind of, although C++ does have an advantage that others lack, it also shares the same symbiotic relationship with UNIX, by having been born on the same place as UNIX and C, by the same group of people of Bell Labs employees and initially started as C pre-processor. Which is also a reason why it cannot get rid of the flaws it inherited from such relationship.

bcrosby95 5y ago

As a long time Java dev, if I could pick a language to migrate to it would be Clojure, Erlang, Elixir, or Golang. In roughly that order.