7 ms·

Lombok is a useful crutch if you're writing lots of Java code on a day to day basis. However, given how easy it is to use Kotlin alongside Java I would question

by ganonm 8y ago

Lombok is a useful crutch if you're writing lots of Java code on a day to day basis. However, given how easy it is to use Kotlin alongside Java I would question whether Lombok is the right solution to the problem. Kotlin has data classes which auto generate sensible 'toString' and 'hashCode' methods which is a massive time saver. Really, if you are considering introducing Kotlin to a Java project I'd recommend you just take the plunge. It's pretty much just a minor change to your pom file (if you're using Maven). Kotlin has Java interop as a primary feature and is flawless from my experience.

kodablah 8y ago
> auto generate sensible [...] 'hashCode' methods Unless you're using arrays. They went with "predictable" over "sensible" here. > is flawless from my experience As a heavy Kotlin user, I'd say it's far from flawless (not sure if you mean interop or the entirety of the language, but applies to both). I'm often creating and starring YouTrack issues. But yes, it's still a highly recommended alternative to Java.
- rufugee 8y ago
  As someone considering using Kotlin for my next project, your comment is interesting. Care to share what flaws you've uncovered?
  - kodablah 8y ago
    Assuming it's for the JVM, you should definitely choose Kotlin for your next project. Most of the flaws I find are for advanced usage (e.g. interop, coroutines, etc) or tooling (e.g. gradle issues, dokka) or just general advanced language use. I don't keep a running list of issues (I made one back in the day [0] but not all of it is still applicable), but nothing would keep me away from the language. It made a lot of right decisions. 0 - https://gist.github.com/cretz/2a49514b18914ef09b7c518db6db116c https://gist.github.com/cretz/2a49514b18914ef09b7c518db6db11...
    - jicea 8y ago
      Jetbrains has a very good 4 weeks free course on Coursera https://www.coursera.org/learn/kotlin-for-java-developers https://www.coursera.org/learn/kotlin-for-java-developers. We’ve beginning to introduce Kotlin in our code based, and also begin to use Kotlin Dsl on our new Gradle projects; for the moment, the experience is excellent. Interop with Java is really good and the support from IntelliJ is also fine.
altmind 8y ago
I agree, it's as easy to tap into your build tool to build kotlin/groovy/scala alongside with java, as it is to tap into buildtool to process the annotations.
kovrik 8y ago
Yeah, Kotlin pretty much killed Lombok.
viach 8y ago
I see Kotlin as a great choice for these who don't want Java verbosity but can't really get used to read Scala.
- jamougha 8y ago
  I can read Scala fine but I'd like fast compilation and good IDE support.
  - jacobn 8y ago
    The IDE support is pretty good these days, as least in IntelliJ.
    - dominotw 8y ago
      Intellij still can't figure out how to handle implicits. At this point i have an intuition about the errors that idea reports as errors but actually aren't'.
      - threeseed 8y ago
        Are you using the latest version of IntelliJ ? Because it does a pretty good job with implicits now: https://blog.jetbrains.com/scala/2018/07/25/intellij-scala-plugin-2018-2-advanced-implicit-support-improved-patterns-autocompletion-semantic-highlighting-scalafmt-and-more/ https://blog.jetbrains.com/scala/2018/07/25/intellij-scala-p...
    - Cyph0n 8y ago
      Not sure why you were downvoted. IntelliJ’s Scala plugin is top-notch in my experience.
      - edejong 8y ago
        True, nor do I understand your downvote.
      - 8y ago
monksy 8y ago
The same can be said about Scala and Groovy. (Groovy brings in those generators via an annotation)
- ninja10 8y ago
  Of those three (Kotlin, Scala, Groovy), Kotlin is by far the most pragmatic. Scala is nice, more powerful, but has a high cost when it comes to learning curve, complexity, and the library ecosystem. I'm not sure of the state of Groovy at this point after it got transferred to the apache foundation. Kotlin on the other hand strikes a nice balance in many areas.
  - pjmlp 8y ago
    Kotlin got a major push on Android, thanks to a stagnant Java 8 support. With ChromeOS and Fuchsia on the game as well, it remains to be seen who will win Google's internal OS wars. So far Android seems to be the one taking them all, though. Outside Android I don't really see a major benefit switching whole teams away from Java, Eclipse/Netbeans and rewriting/wrapping libraries to be idiomatic Kotlin and such.
  - dmux 8y ago
    How do you define pragmatic? Apache Groovy is still under active development. We've actually started using it more for green-field development where I work.
    - willtim 8y ago
      What exactly does "Groovy" offer that another JVM based language doesn't? Am genuinely interested.
      - zmmmmm 8y ago
        Not the parent, but I prefer Groovy over other JVM languages because: - supports both dynamic and static typing - it works just as well for bash level scripting as it does for full application development. For example, you can use it exactly like an interpreted language (no compilation needed). - seamless Java integration. I know many JVM languages say that, but Groovy actually makes it one of its core features. It has a lower impedance mismatch than any other JVM language I've tried (and I try them all). - partly because of the dynamic typing, it is able to support the most concise, powerful options in its syntax of any of the JVM languages. So you get more done with fewer, simpler lines of code - because of the static typing and low impedance mismatch with Java, it can achieve very high performance. I was not able to get Scala to perform as well, for example, because of type conversions needed to invoke underlying Java library calls (unless you abandon idiomatic Scala).
pjmlp 8y ago
Kotlin has not flawless integration and some attention is required when writing libraries for Java consumption. Additionally the JVM wasn't enough for JetBrains and code written for multi-platform has slightly different semantics (see Kotlin/Native and immutable data). Kotlin is a good alternative on Android due to a frozen Java 8. Against Java 12 not so much. It is very hard to displace platform languages when others just feel like guests.
- dtech 8y ago
  I would argue that Kotlin brings massive benefits over Java 12: * Excellent null safety enforced by the type system * Data classes reduce boilerplate and bug sources * Extension methods * Declaration site variance removes a lot of the ? extends T * Everything being an expression (if, switch/when) is powerful * Smart casts are useful, especially when combined with subtypes and when (switch) * Removal of checked exceptions * Inline functions, a good way to work around runtime type erasure * Properties, no more getX or setX None of these are the killer reason to go over to Kotlin or another JVM language, but all combined they make building software much more efficient. Java could get all of these, but they've tried to increase feature delivery speed multiple times by adjusting release schedule and failed so far.
  - pjmlp 8y ago
    I give it 5 years time for Kotlin to be having beers with Scala, Clojure, Groovy, Beanshell, Ceylon, XTend in terms of global JVM developer market share (I do not count Android as part of JVM market). https://trends.google.com/trends/explore?geo=US&q=java,kotlin,scala,Clojure https://trends.google.com/trends/explore?geo=US&q=java,kotli... Specially since JetBrains decided that they not only want to go against Java, they are also positioning Kotlin agoainst JavaScript, TypeScript, WebAssembly languages, C, C++, Rust, .... Ergo choosing multiple fronts to focus on. Which already has the consequence that Kotlin/Native code does not fully follow the same semantics. Also regardless of what people in HN think, Eclipse still rules the enterprise and the Kotlin plugin is a bit meh playing catchup with latest features. Most IT departments won't sign off InteliJ licenses just because some devs think Kotlin is cool. It is not language feature bullet points that make an eco-system, specially for those that don't own platforms.
nine_k 8y ago
Kotlin is great. But go and try to persuade your company to bless another language for production. It may be easy when your engineering org is 5 persons. It's much harder, genuinely harder, when it's 250 engineers, and an hour of downtime costs hundreds of thousands. Adoption of another language, even clearly superior and interoperable, becomes a large and costly undertaking. So "just use Kotlin" is not always possible, and I'm thankful to Lombok's authors for their work.
- tandr 8y ago
  I am not parent commenter, but your comment really struct the chord here. I failed to convince 2 people (my mgr and team-lead) for our relatively-green-field project 2 years ago to use Kotlin... Thing is - same people killed an idea to use Lombok as well. So it is an uphill crawl no matter how "big" is the change - it is how comfortable people are with what you are proposing, and where they (and you) are in a command (aka responsibility-and-headache-if-something-new-goes-wrong) chain.
- ec109685 8y ago
  You’d have to spending 192M a year on developers for 1 hour of downtime to cost hundreds of thousands.

by ganonm 8y ago

kodablah 8y ago

> auto generate sensible [...] 'hashCode' methods Unless you're using arrays. They went with "predictable" over "sensible" here. > is flawless from my experience As a heavy Kotlin user, I'd say it's far from flawless (not sure if you mean interop or the entirety of the language, but applies to both). I'm often creating and starring YouTrack issues. But yes, it's still a highly recommended alternative to Java.

rufugee 8y ago
As someone considering using Kotlin for my next project, your comment is interesting. Care to share what flaws you've uncovered?
- kodablah 8y ago
  Assuming it's for the JVM, you should definitely choose Kotlin for your next project. Most of the flaws I find are for advanced usage (e.g. interop, coroutines, etc) or tooling (e.g. gradle issues, dokka) or just general advanced language use. I don't keep a running list of issues (I made one back in the day [0] but not all of it is still applicable), but nothing would keep me away from the language. It made a lot of right decisions. 0 - https://gist.github.com/cretz/2a49514b18914ef09b7c518db6db116c https://gist.github.com/cretz/2a49514b18914ef09b7c518db6db11...
  - jicea 8y ago
    Jetbrains has a very good 4 weeks free course on Coursera https://www.coursera.org/learn/kotlin-for-java-developers https://www.coursera.org/learn/kotlin-for-java-developers. We’ve beginning to introduce Kotlin in our code based, and also begin to use Kotlin Dsl on our new Gradle projects; for the moment, the experience is excellent. Interop with Java is really good and the support from IntelliJ is also fine.

altmind 8y ago

I agree, it's as easy to tap into your build tool to build kotlin/groovy/scala alongside with java, as it is to tap into buildtool to process the annotations.

kovrik 8y ago

Yeah, Kotlin pretty much killed Lombok.

viach 8y ago

I see Kotlin as a great choice for these who don't want Java verbosity but can't really get used to read Scala.

jamougha 8y ago
I can read Scala fine but I'd like fast compilation and good IDE support.
- jacobn 8y ago
  The IDE support is pretty good these days, as least in IntelliJ.
  - dominotw 8y ago
    Intellij still can't figure out how to handle implicits. At this point i have an intuition about the errors that idea reports as errors but actually aren't'.
    - threeseed 8y ago
      Are you using the latest version of IntelliJ ? Because it does a pretty good job with implicits now: https://blog.jetbrains.com/scala/2018/07/25/intellij-scala-plugin-2018-2-advanced-implicit-support-improved-patterns-autocompletion-semantic-highlighting-scalafmt-and-more/ https://blog.jetbrains.com/scala/2018/07/25/intellij-scala-p...
  - Cyph0n 8y ago
    Not sure why you were downvoted. IntelliJ’s Scala plugin is top-notch in my experience.
    - edejong 8y ago
      True, nor do I understand your downvote.
    - 8y ago

monksy 8y ago

The same can be said about Scala and Groovy. (Groovy brings in those generators via an annotation)

ninja10 8y ago
Of those three (Kotlin, Scala, Groovy), Kotlin is by far the most pragmatic. Scala is nice, more powerful, but has a high cost when it comes to learning curve, complexity, and the library ecosystem. I'm not sure of the state of Groovy at this point after it got transferred to the apache foundation. Kotlin on the other hand strikes a nice balance in many areas.
- pjmlp 8y ago
  Kotlin got a major push on Android, thanks to a stagnant Java 8 support. With ChromeOS and Fuchsia on the game as well, it remains to be seen who will win Google's internal OS wars. So far Android seems to be the one taking them all, though. Outside Android I don't really see a major benefit switching whole teams away from Java, Eclipse/Netbeans and rewriting/wrapping libraries to be idiomatic Kotlin and such.
- dmux 8y ago
  How do you define pragmatic? Apache Groovy is still under active development. We've actually started using it more for green-field development where I work.
  - willtim 8y ago
    What exactly does "Groovy" offer that another JVM based language doesn't? Am genuinely interested.
    - zmmmmm 8y ago
      Not the parent, but I prefer Groovy over other JVM languages because: - supports both dynamic and static typing - it works just as well for bash level scripting as it does for full application development. For example, you can use it exactly like an interpreted language (no compilation needed). - seamless Java integration. I know many JVM languages say that, but Groovy actually makes it one of its core features. It has a lower impedance mismatch than any other JVM language I've tried (and I try them all). - partly because of the dynamic typing, it is able to support the most concise, powerful options in its syntax of any of the JVM languages. So you get more done with fewer, simpler lines of code - because of the static typing and low impedance mismatch with Java, it can achieve very high performance. I was not able to get Scala to perform as well, for example, because of type conversions needed to invoke underlying Java library calls (unless you abandon idiomatic Scala).

pjmlp 8y ago

Kotlin has not flawless integration and some attention is required when writing libraries for Java consumption. Additionally the JVM wasn't enough for JetBrains and code written for multi-platform has slightly different semantics (see Kotlin/Native and immutable data). Kotlin is a good alternative on Android due to a frozen Java 8. Against Java 12 not so much. It is very hard to displace platform languages when others just feel like guests.

dtech 8y ago
I would argue that Kotlin brings massive benefits over Java 12: * Excellent null safety enforced by the type system * Data classes reduce boilerplate and bug sources * Extension methods * Declaration site variance removes a lot of the ? extends T * Everything being an expression (if, switch/when) is powerful * Smart casts are useful, especially when combined with subtypes and when (switch) * Removal of checked exceptions * Inline functions, a good way to work around runtime type erasure * Properties, no more getX or setX None of these are the killer reason to go over to Kotlin or another JVM language, but all combined they make building software much more efficient. Java could get all of these, but they've tried to increase feature delivery speed multiple times by adjusting release schedule and failed so far.
- pjmlp 8y ago
  I give it 5 years time for Kotlin to be having beers with Scala, Clojure, Groovy, Beanshell, Ceylon, XTend in terms of global JVM developer market share (I do not count Android as part of JVM market). https://trends.google.com/trends/explore?geo=US&q=java,kotlin,scala,Clojure https://trends.google.com/trends/explore?geo=US&q=java,kotli... Specially since JetBrains decided that they not only want to go against Java, they are also positioning Kotlin agoainst JavaScript, TypeScript, WebAssembly languages, C, C++, Rust, .... Ergo choosing multiple fronts to focus on. Which already has the consequence that Kotlin/Native code does not fully follow the same semantics. Also regardless of what people in HN think, Eclipse still rules the enterprise and the Kotlin plugin is a bit meh playing catchup with latest features. Most IT departments won't sign off InteliJ licenses just because some devs think Kotlin is cool. It is not language feature bullet points that make an eco-system, specially for those that don't own platforms.

nine_k 8y ago

Kotlin is great. But go and try to persuade your company to bless another language for production. It may be easy when your engineering org is 5 persons. It's much harder, genuinely harder, when it's 250 engineers, and an hour of downtime costs hundreds of thousands. Adoption of another language, even clearly superior and interoperable, becomes a large and costly undertaking. So "just use Kotlin" is not always possible, and I'm thankful to Lombok's authors for their work.

tandr 8y ago
I am not parent commenter, but your comment really struct the chord here. I failed to convince 2 people (my mgr and team-lead) for our relatively-green-field project 2 years ago to use Kotlin... Thing is - same people killed an idea to use Lombok as well. So it is an uphill crawl no matter how "big" is the change - it is how comfortable people are with what you are proposing, and where they (and you) are in a command (aka responsibility-and-headache-if-something-new-goes-wrong) chain.
ec109685 8y ago
You’d have to spending 192M a year on developers for 1 hour of downtime to cost hundreds of thousands.