Hacker News Reader

Comment by ganonm | Hacker News Reader

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.

View on HN

> 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.

As someone considering using Kotlin for my next project, your comment is interesting. Care to share what flaws you've uncovered?

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/2a49514b18914ef09b7c518db6db11...

Jetbrains has a very good 4 weeks free course on Coursera 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.

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.

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.

You’d have to spending 192M a year on developers for 1 hour of downtime to cost hundreds of thousands.

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

I can read Scala fine but I'd like fast compilation and good IDE support.

The IDE support is pretty good these days, as least in IntelliJ.

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'.

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-p...

Not sure why you were downvoted. IntelliJ’s Scala plugin is top-notch in my experience.

True, nor do I understand your downvote.

+1 works great

Apart the fact that I would disagree on intellij support, what about the other ides? Eclipse? Visual studio (not code)?

Scala support in IntelliJ is ok, but still not great. There are some Akka constructs IntelliJ underlines in red for years and JetBrains doesn't fix it. I've never seen something like that with Kotlin.

The hard truth is that Scala was not designed with tool support in mind and it probably never will be. For example hierarchical implicit conversions, while powerful, are terrible for tooling.

> Scala was not designed with tool support in mind and it probably never will be

You should pay attention to what's going on in the ecosystem. Dotty comes with LSP support. The Scala Center's main focus is tooling. JetBrains has been pretty committed and cooperating as of late. And several projects are building serious alternatives to SBT.

Agree. In fact, we have a rule in our team that if a feature is not supported by IntelliJ, then it's probably too arcane and should not be used.

Scala syntax is decent tbh, unless you decide to go overboard with operator overloading.

Most libraries — SBT is one example — have shifted away from the use of excessive overloading.

That time when my boss started using "implicit" on everything. We were even using a new "Functional Relational Mapping" framework from Lightbend/Typesafe called Slick which was a mess.

Tend to agree. But if you work in a team, there will be someone who just loves implicits and overloading and you won't be able to change his mind. Strong code style policies help, but they are really rare in real processes.

Your team can make a decision as a group to not allow defining operators in the team's codebase. As you mentioned you can then enforce that with scalastyle (set FieldNamesChecker and MethodNamesChecker regexes to ^[a-z][A-Za-z0-9_]*$). Is that not enough to handle the one person who loves overloading?

Yeah, Kotlin pretty much killed Lombok.

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.

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.

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,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.

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

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.

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.

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.

What exactly does "Groovy" offer that another JVM based language doesn't? Am genuinely interested.

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).

The seamless integration is amazing. For a lot of existing Java code, it's as simple as renaming the file to .groovy. In addition to your list, some of our most used features are

- The amazing SQL library - HTML builders (there are XML builders too) - Literal collections (lists and maps)

> For a lot of existing Java code, it's as simple as renaming the file to .groovy

This causes the program to run in dynamically-typed mode, much sloooower, so why do it? You'd have to add @Static annotations everywhere to get anything approaching Java-like speeds. One of the Apache Groovy project managers has long since wanted to make Groovy statically compiled by default, but that's never going to happen because they're running an unofficial go-as-slow-as-possible in the official upcoming upgrade to Groovy 3.

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.

Reply on news.ycombinator.com