Lombok addresses one pain point of Java (constructors/getters/setters), Kotlin addresses more. Lombok also does a bit of magic, so should be used with care. E.g. @AllArgsConstructor is a dangerous one if you change the order of fields, especially if you don't have IDE support for Lombok.

Not sure where the danger is with @AllArgsConstructor. If you change the order of fields, it's the same as if you changed the order of the constructor parameters. You'll get compile errors and be forced to fix them (IDE or not). Seems as safe as anything to me.

That assumes your constructor parameters are all unique types.

I would consider that a bit of a design smell, but yes. I think the danger point has more to do with training new converts: it is very unusual in any language that changing the order of class internals can change its external behavior.

I was going to write something similar. My takeaway from the article is that Kotlin is perhaps a very minor improvement over Java + Lombok + some functional libraries like Vavr.

This is actually my biggest complaint about Kotlin; it doesn't bring much to the table that is very new. If I'm going to move on from Java I want something more exciting like Ceylon's union & intersection types (which I get to use in... Typescript).

As a non-Java dev, Lombok seems like the kind of thing that could only be tolerated by Stockholm syndrome java devs :/

I mean, it's a clever solution and the site/documentation is great. But tossing around annotations everywhere feels hacky as hell, not to mention that it only works with IDEs. I'm sure the combination you mentioned approaches Kotlin in terms of features and QoL improvements, but it's just so much nicer to have these things built into the language. Plus, Lombok is mostly constrained to boilerplate reduction - Kotlin may not be as "crazy" as Scala, but it still has some really nice modern features that java doesn't have/can't have/won't have for a long time.

As a polyglot, I don't understand your problem with annotations. These really aren't different:

    @Getter @Setter String foo;

    attr_accessor :foo

It's unfortunate that Java chose the silly capitalization convention for properties instead of something more structured like C#'s get/set, but that's really an aesthetic complaint.

I think this is the case with most JVM languages, to be honest. As someone who has done some Java but would never do it willingly as part of a hobby project or the like I think Kotlin and pretty much every other JVM language is a huge step up from Java.

When you're already knee deep in it I suppose you're bound to have a less enticing reason to use the other languages.

That being said, I don't see how you can look at the feature list of Kotlin and play around with it without seeing how it's obviously a much better language.

> ...not to mention that it only works with IDEs.

That's not true. Lombok is an annotation preprocessor. That means it is running with javac which is independent of any build tools or IDEs. As long as it is on the classpath when compiling (-cp flag of javac) it works.

Of course for code completion you need an editor that is aware of Lombok / uses the compiled bytecode for that.

There's rarely a need for a language with anything "new".

There's a strong need for a language that brings the best ideas recently developed and puts them together in a new language that does not have baggage from the past, (e.g. D).

I've never used Lombok or any other code generator with Java.

I think the important features of Kotlin are:

- Null checking

- Proper lambda/function types

- Not everything has to be a class

- You can specify parameter name when passing to functions: specially useful when constructing objects.

- Simplified constructors (member fields can be specified in the argument list).

These were some of my biggest pet peeves with Java.

That, and the weird stream APIs.

Pitfalls of Lombok aside, I agree that it is indispensable to reduce the amount of boilerplate in Java. That being said, it is largely a hack but most of the IDEs have Lombok support so it's not _as_ bad.

AutoValue beats Lombok hands down. Not least because it is pure Java so no extra IDE support is needed.

Using Lombok is just as much effort as adopting another JVM language (you still have to teach all your tools about Lombok, adapt all your processes, teach anyone you hire...), for a smaller reward, IME.

(I used to use Lombok, the checkers framework, and various other pieces. I found Scala gave me all of that and more, for a similar level of effort)