
Lombok makes Java cool again - rdonovan
https://bytes.grubhub.com/lombok-makes-java-cool-again-171102bdcc52
======
ganonm
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.

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

------
apo
Annotation-based programming might seem cool now, but wait a few years.

Magic always seems cool when you add it to a project - hey, look - I don't
have to do <tedious thing> anymore.

Then time goes on, and you (or your successor) opens up the project to track
down a bug. Only there's no logical flow - things just seem to happen as if by
magic.

Lombok strikes me as magic in these ways.

I actually had to go to the project home page to figure out what problem it
solves:

[https://projectlombok.org](https://projectlombok.org)

The examples refer to a specific kind of boilerplate, namely the kind that
comes from treating classes a dumb bags of properties. Getters directly
returning private fields. toString methods, etc.

An alternative approach to Lombok would be to think about how the project
ended up with so many dumb data classes. How could the project be refactored
to eliminate them, for example?

Doing so would avoid the need for magic and produce a code base in which
effect followed cause.

~~~
arcticbull
I liked to refer to the genre as MOP -- Magic Oriented Programming. Every
ecosystem I've seen go down that route ends up bailing out. A good example of
this would be Apple's Cocoa Bindings [1] on macOS that were killed with fire
when the iOS APIs were defined, and KVO [2] which is flat out rejected at
every company I've ever worked.

On the other hand, when built into the language, this kind of explicit but
automatic code generation can be awesome (as in Rust's #[derive()] traits [3])
but I think the difference there is the compiler/language vendor agree to
support it indefinitely.

[1]
[https://developer.apple.com/library/archive/documentation/Co...](https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CocoaBindings/CocoaBindings.html)

[2]
[https://developer.apple.com/library/archive/documentation/Co...](https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/KeyValueObserving/KeyValueObserving.html)

[3] [https://doc.rust-lang.org/rust-by-
example/trait/derive.html](https://doc.rust-lang.org/rust-by-
example/trait/derive.html)

~~~
Illniyar
Rails would be the opposite example. Magic all the way down and the ecosystem
is not even contemplating the idea of bailing on it.

~~~
raducu
Yes, but as a programmer when I'd start working on a new project, I would call
it a Rails project, I've never heard of a Lombok project.

Sure, I've seen Spring/J2EE projects that used Lombok... some 10 years ago,
but the idea seemed to have died down, maybe it's my own bubble.

Automagic is ok for a specific type of problem (Rails for webaps?), Lombok
however reminds me a bit of the promises of AOP which failed to gain traction
outside frameworks.

There are other highly opinionated frameworks/stacks that have mixed adoption
in the java world -- jhipster seemed to gain some traction, but people seem to
just use bare spring boot nowadays(which is quite opinionated)

I don't have absolutely anything against small projects, I'd love to work more
on smaller projects, but 18000 lines of generated code is NOTHING, try to
convince a medium team to use Lombok, you'll very soon end up with people
loving or hating it, removing it for debugging purposes, creating their own
generators and very soon it's a real mess. But all that is just my experience,
I'm not trying to dismiss Lombok or any approach, if it works for you, great!

~~~
geezerjay
> I've never heard of a Lombok project.

You've must have heard about Spring projects. I'm yet to come across a Spring
project that doesn't use lombok.

> Sure, I've seen Spring/J2EE projects that used Lombok... some 10 years ago,
> but the idea seemed to have died down, maybe it's my own bubble.

Perhaps it's my bubble as well but I'm still seeing Spring projects in
production today that feature lombok extensively.

Not all organizations are willing to burn through cash to jump to the flavor
of the month every couple of months. If you deployed a system and the system
works, you need to discover a very good reason to throw a revolution and start
from scratch with a new tech stack.

------
vbsteven
Spring boot with Lombok has been my go to framework for a few years now.
Annotation-based programming seems to get a lot of negative attention here on
HN, and it definitely is not perfect but there is just no other framework that
(in my opinion) comes close in terms of productivity and workflow.

Currently I'm building my SaaS + Selfhosted software licensing product with
this Spring Boot + Lombok + Postgresql combo and Annotations are helping me
out for :

* @Bean, @Autowired, @Profile,... for configuring dependency injection with multiple profiles (saas vs selfhosted)

* @Entity, @Table, @Repository, @Enumerated, @Embedded for mapping my classes to Database tables

* @Api, @ApiOperation, @ApiParam,... for generating Swagger documentation for my endpoints

* @GetMapping, @PostMapping, @PreAuthorize for configuring and authorizing my endpoints

* Lombok @Data, @Value, @Builder for tedious boilerplate generation

* @NotNull, @NotBlank, @Email, @PhoneNumber, @Pattern(regex), @Length(max=12),... for validation of form input, api params and database models.

* @JsonProperty, @JsonSerialize, @JsonIgnore for configuring json deserializing for my DTO's

* @Value("${my.config.key}") for decoupling configuration from my code and injecting values at runtime

I probably forgot a few more use cases. All of these are pretty
straightforward, are defined alongside the code they are modifying or
interacting with and would lead me to a lot of lost time and a lot more code
if I were to implement them myself, or configure them by hand "in real java
code".

~~~
raz32dust
While it is great while you are trying to get your product to market quickly,
I would highly recommend getting rid of all these annotations as soon as you
can. Preferably before your team grows to 5+ people or complexity grows beyond
around 100k lines of code. It's hard to explain this to people from non-Java
background, but the time writing non-annotation code will save you in
debugging and maintainability is well worth it beyond that point.

~~~
vbsteven
I can see that the dependency injection annotations can be complex for people
not experienced with the whole Spring/IoC/DI setup. I have some rules and
general guidelines I use for keeping them in check which I can explain in
about 10minutes (and have done to team members in a few companies)

Honestly, I prefer to debug with annotations and a debugger over a manually
coded configuration class with hundreds of lines of wiring components
together.

And for removing the other annotations: Why should I decouple apidocs from my
code? They are litterally annotating the source code so it makes sense to have
them close.

Stuff like the validators and JSON properties and configuration also makes
sense to have them close to the fields that they are about instead of in a
separate JsonSerializer class or whatever.

------
diegof79
I use the elements of programming from SICP[1] as a litmus test for this kind
of frameworks.

The main issue with these annotation hacks is that they fail in the area of
“means of combination” and “means of abstraction”.

For example if you have: @X @Y class Something{}

You cannot tell if X & Y can be combined (or how it’s combined), or you cannot
easily create an abstraction Z with X and Y (you may be able to do that but it
requires framework support and usually is painfully impractical)

It seems to be a small issue compared to the added value, but to me is not. As
the code base grows the maintenance and debugging issues grow too... in the
end probably is better to use Kotlin or Scala.

[1]: [https://mitpress.mit.edu/sites/default/files/sicp/full-
text/...](https://mitpress.mit.edu/sites/default/files/sicp/full-
text/book/book-Z-H-10.html#%_sec_1.1)

~~~
ajkjk
I agree, but it's helpful that the things Lombok abstracts away are very
idiomatic and straightforward. I would never want to use it to take on
anything more complicated.

------
zestyping
Reading this just reminds me of all the terrible things about Java. The lack
of reasonable default string representations, comparison and hashing methods,
etc. are all glaring mistakes in the language design that have wasted huge
amounts of time for millions of programmers. It's as though Java programmers
are so deep in the grips of Stockholm Syndrome that ordinary, sensible
behaviour seems amazing and "cool".

This is similar to the situation with design patterns. When design patterns
came along, Java folks talked about them as though they were a wonderful new
invention. But they only exist because Java is so clumsy that it needed
crutches to do things that had been easy and natural in other languages for
years; someone merely came along and gave the crutches names.

~~~
fraggle222
You either like strongly typed object oriented langs or you don't. If you do,
then a bit of verbosity is really nothing. If there are actual lang
improvements beyond saving me a few characters, I'll take them.

~~~
jrockway
I don't think that any of Java's warts are related to liking strongly-typed
object oriented languages. I think the standard library is Java's biggest
problem (read through the code that's been around since the 1.0 days, it's
AMAZING in the way that a car crash is amazing). The community has done a good
job building a better standard library (back when I did Java it was Guava,
maybe that's not the state of the art anymore), and that helped a lot.

All in all, I am not a fan of OO anymore. I like the computer science
principles behind it, but practical programs never use them. They always get
Liskov Substitution backwards. People always use subclasses for cases like
"give me the superclass, but with these conditions" which is the exact
opposite of what you're "supposed" to do. Problem is making your subclass less
restrictive is largely useless, what people really want is copy-paste without
having to maintain two copies of the code. So there is some mismatch to what
programmers and computer scientists call classes, and the result is that you
get a mess. I'm not sure that's Java's fault or its largest problem, but it
isn't helping.

~~~
edejong
All these words for saying: I think class inheritance is a bad idea. Lots of
folks agree. Rust might be your thing!

------
mohaine
My main issue with Java is all the annotation based programming. Some of these
are nice and can make the easy case super easy but if you need go even
slightly off the easy path you seem to quickly loose all the time gained on
the easy path.

i.e.

@GET(url="[http://host/users/$userid"](http://host/users/$userid")) public
abstract User getUser(String userid)

isn't that much easier than the python requests version but much harder if you
need to add a custom dynamic header to the call.

~~~
dangets
Yep. I love data classes for the simplicity and utility but pretty soon there
are more annotations than java code. In Java I prefer Immutables over Lombok
but once you add Jackson annotations, customize the Immutables generated code
(@Value.Immutable, @Value.Parameter, etc), add some javax.validation
(@NotNull, @NotEmpty) it gets very noisy very quickly. And yet it is _still_
better than writing mutable bean classes by hand IMHO.

Switching to / mixing in Kotlin is worth it just for the data classes at this
point (and you get _some_ type-level nullability and `val` instead of `final
var` to boot).

[https://immutables.github.io/](https://immutables.github.io/)

~~~
guapo
Or just register the Jackson Java 8 datatypes module.

Then you can create a standard immutable class with a constructior, and
Jackson's object mapper can then serialize and deserialize.

The only catch is that you must add -parameters to your javac args.

~~~
Shawnecy
This is what I do. Can attest that it keeps things very clean and lean.

------
platelminto
I'm interested in the downsides of using Lombok, since the article seems to
only focus on its positives and makes it seem like I should download it and
start using it right now.

Is there anyone here with Lombok experience that wants to share any issues
they've run into while using it? All I can think of right now is the fact that
the source code isn't compatible with Java.

~~~
batter
Just recently removed Lombok from one of our projects. 1\. To use it you have
to use plugin for each IDE. If project not frequently used, spending time for
each developer here doesn't make any sense. 2\. Another reason was, person who
used Lombok abused all OOP principles. Project became a book of anti-patterns.

~~~
bobthepanda
Idiots can do all sorts of terrible things with any tool given enough time and
effort. That's not really Lombok's fault.

------
ilovecaching
It’s ok to let languages die; we’re just barely scraping out of the infancy of
programming. Languages like Java and C++ which have carried us a long way need
to evolve into new and better languages that incorporate lessons learned and
the next wave of research.

We also know from Google’s paper on software practices that software naturally
gets rewritten over time, at a cadence that makes it acceptable to switch
languages. So there is really no reason not to have a plan for your business
to migrate languages periodically.

Unfortunately the industry seems to be stuck in a rut, and we’re forced to
retrofit ancient compilers like horse drawn buggies with plate armor and
machine guns on them.

~~~
ehnto
I see the opposite. I see an industry all too willing to throw away years of
hard earned knowledge, experience and purpose built tools in order to chase
the shiny tools the popular kids are using.

New tooling often follows a commom cycle of being light weight because they
ditched the stuff that looked unecessary. Then slowly a whole ecosystem of
plugins and libraries springs up to rebuild the missing tools. Like the bottom
bracket tool in a bicycle tool box. I have never used one, but when I need one
no other tool would work.

I do truly believe that there is mastery in advanced, long lived tooling and
efficiency may not lie with a new language but in truly understanding a
comprehensive set of ordinary tools.

Languages also tend to be just the building blocks for the real tools, which
are the frameworks and libraries built with them. So I hesitate to throw away
my hard earned knowledge only to re-learn another artisan MVC framework
written in a prettier language.

I concede that the parade must go on though, and ultimately I have to pay the
bills. If precompiled serverside React is where the money is then... so be it.

~~~
blr_traffic
> an industry all too willing to throw away years of hard earned knowledge,
> experience and purpose built tools in order to chase the shiny tools the
> popular kids are using.

Why do you think people in the industry are doing this? There must be multiple
factors behind this.

~~~
ArloL
My take on it is that it boils down to the profession being so young. Since
it's so young we have a lot of young developers ( < 10 years experience).
Programming is an inherently complex task [0]. Couple that with Not-Invented-
Here and favoritism of barely working solutions (meaning by businesses: [1])
and as a result you get extremely fluctuating stacks. Every piece of code
written by others was never written with care [2] - that is the assumption at
least because more often that not it's true. Everyone in their own right
thinks that only their code works well and has some special properties but in
the end you face the exact same problems: problems of design rather than
implementation.

[0] [http://worrydream.com/refs/Brooks-
NoSilverBullet.pdf](http://worrydream.com/refs/Brooks-NoSilverBullet.pdf)

[1]
[https://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/E...](https://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1036.html):
the business community, which, having been sold to the idea that computers
would make life easier, is mentally unprepared to accept that they only solve
the easier problems at the price of creating much harder ones

[2] See why Martin Fowler stresses Technical Excellence basically every time
he get's on stage:
[https://www.youtube.com/watch?v=G_y2pNj0zZg](https://www.youtube.com/watch?v=G_y2pNj0zZg)

------
chooseaname
Java the language is cool. What the enterprise has done with it is _not_ cool.
Writing apps with layer upon layer upon layer upon layer of abstraction is ...
self defeating. Then they'll holler, we need to rewrite it! All in the name of
finding that one true architecture that can handle any business CR. Blech.

~~~
dajohnson89
How do you feel about Spring? I'm a fan of Java itself as well, but find
myself conflicted whenever I use Spring/Boot. It's very nice when it works.
But when the magic formula isn't recited correctly....you get frustrated and
wind up visiting HN to forget about how unpleasant it is.

 _ahem_

~~~
pjmlp
I think that it brought a good competition against JEE (back when it was still
J2EE), however I would still just use JEE for Java Web projects.

~~~
dajohnson89
Just curious -- why?

~~~
pjmlp
Short answer, experience and employers.

My experience doing Web development in Java started with joining a team that
was ramping up a project on WebSphere 5.1, alongside a migration from BEA
WebLogic.

I went through a couple of WebSphere, JBoss and TomcatEE versions up to JEE 6,
was the technical lead for an in-house JSF framework built on top of
RichFaces, and on very last JEE project used PrimeFaces.

All the employers that I worked for, mostly used JEE stacks for their Java
projects. Spring was the exception, rather than the norm.

Additionally, even if a bit slowly, many of the Spring improvements ended up
in JEE and Spring also supports the JSR related to JEE anyway.

Nowadays I live in the .NET world, and the Java teams next door are happily
delivering JEE based solutions.

So if I was suddenly asked to architect a Java based solution, naturally it
would be JEE based.

------
afpx
Please don't.

Why? It adds more time to the build, it requires plugins to work effectively,
and it confuses the hell out of people when they expect to see Java. If you
really want a better syntax, use Scala or Kotlin (I'm a _huge_ Scala convert).

------
saagarjha
> Although Java is one of the most popular JVM languages

Is it not _the_ most popular JVM language?

~~~
berbec
Is it not the definition of a JVM language?

~~~
chvid
Java is by far the most popular JVM language - probably by a factor of at
least 10.

~~~
isbvhodnvemrwvn
10 is a low estimate. I'd say it's more like 20, with Scala dominating the
rest.

------
hota_mazi
At this point, it's less disruption to a Java project to start writing it in
Kotlin than adding Lombok to it.

------
dionian
Lombok solves one of the major problems with Java, but doesnt solve a million
others. Scala, Kotlin, or Clojure are way better alternatives...

------
eweise
We initially used lombok to decrease the pain of writing in Java but
eventually moved to Kotlin and are sooo much happier.

~~~
BtdTom
Kotlin is great and very easy to use if you already know Java.

------
rubyfan
Annotations have always come across as a crutch. It’s noisy at best and
unsightly in large concentrations.

------
the-alchemist
i also wanna give a shoutout to
[https://immutables.github.io/](https://immutables.github.io/) over Lombok. No
AST magic, and even optimized Jackson/GSON code.

~~~
JanecekPetr
This, a million times.

In my professional bubble Lombok is completely gone. I'll go as far and say
that modern Java does not use Lombok. Smaller, focused libraries like
Immutables or AutoValue, solve the problem of boilerplate for data classes.

Lombok tries to do too much across many concerns, in a fairly opaque way, and
makes the code and tooling around it more magic than it needs to be.

Skip Lombok. Modern Java is better off without it...

------
koolba
What's the point of this part of the generated Java code? (I split it out onto
multiple lines for legibility)

    
    
        favoriteFoods = new java.util.LinkedHashSet<String>(
          this.favoriteFoods.size() < 1073741824
            ? 1 + this.favoriteFoods.size() + (this.favoriteFoods.size() - 3) / 3
            : Integer.MAX_VALUE
        );
        favoriteFoods.addAll(this.favoriteFoods);
    

Why not just?

    
    
        this.favoriteFoods = new java.util.LinkedHashSet<>(this.favoriteFoods);

~~~
notamy
1073741824 is maximum (signed) integer size divided by 2. This is trying to
optimize for the initial size of the set so that it doesn't have to allocate
too many elements, since iirc Java's hashsets are backed by a hashmap
implementation which has to be sized appropriately.

~~~
koolba
I understand what it’s doing. I’m curious why it’s necessary to do it
explicitly. Wouldn’t the optimal sizing be the default behavior when passing
in the collection that will populate the set?

------
salvadormon
I helped in the development of a microservice as a third party developer for a
big lodgings reservation company.

The infrastructure team of the main company forced us to include Lombok and
use it and the code was a mess. Too much automagically generated code that was
hard to debug.

My company managed to deliver the microservice with enough quality, but I
really hated the experience with Lombok, vanilla Java with the libraries
needed for the task is more than enough (more control over your code).

------
spricket
Lombok is awesome. There's still some painful stuff in Java but Lombok gets
rid of most of it. I agree with other comments about using Kotlin instead, but
I've had a ton of resistance to switching languages since all our devs know
java.

Since Lombok is "just a library" I've managed to sneak it in almost every
project I've worked on. Deftly used, I swear it cuts the LoC in a project by
30%

------
grahamm
I use Lombok all the time. Yes it has some awful bits but generally it's
positives outweigh it's negatives.

------
LeanderK
I think java made some wrong decision, with bigggest one being very pragmatics
generics-addition, resulting in trouble down the road like List<int> not being
possible. But I don't think checked exceptions are one of them ;) I don't like
too much flexibility in a language that has strong types. If you undermine the
type-system, why not code in python? But some additions of Lombok seem
worthwile.

~~~
kodablah
> I don't think checked exceptions are one of them

While they may not have been the wrong decision, empirical evidence
continually shows they add a syntactical burden many devs just work around
(e.g. just wrap in a RuntimeException anyways). It's understandable why most
modern languages don't consider predictable exceptions as part of the function
signatures (though many discourage exceptions altogether in all but the most
extreme cases).

~~~
hota_mazi
This is similar to saying that since error codes are ignored by most
developers, functions shouldn't bother returning them at all.

Error conditions captured in the type system are a vital part of making code
robust. The fact that some developers don't know how to properly handle these
error cases doesn't change anything to the soundness of checked exceptions.

~~~
kodablah
> This is similar to saying that since error codes are ignored by most
> developers, functions shouldn't bother returning them at all.

It's not like saying they shouldn't return them (unchecked exceptions exist),
it's like saying they shouldn't be forced to check the error code or declare
that they will return that error code themselves. Checked exceptions aren't
sound when in practice the same ones are reused to mean many things. And we
shouldn't pretend deciding whether an exception should or shouldn't be checked
is an objective choice applied the same way across the ecosystem.

~~~
hota_mazi
Checked exceptions are the compiler forcing the developer to consider error
cases.

What's not to like about that?

Contrast with all the other approaches (runtime exceptions, return codes,
Either/Result, etc...) where the developer can happily ignore errors, the code
will compile, and then crash at runtime.

~~~
erik_seaberg
I'd be happier with checked exceptions if Java assumed that

    
    
      list.stream().map(doStuff)
    

might throw whatever doStuff might throw, but instead map is defined so that
doStuff can never throw any checked exception, which requires smuggling out
every real-world failure mode.

------
pjmlp
Java is cool, no need for crutches like Lombok.

~~~
mindcrime
True, but Groovy is even cooler!

~~~
EmpirePhoenix
Only for small stuff, if you have a 100k lines project you are absolutely
unable to maintain it while staying sane.

~~~
zmmmmm
I think you definitely need to approach a 100k line project differently to
smaller code (for example declare types more often, static type at least your
interfaces and methods, etc) - but it is completely possible to write Groovy
in a style that scales to that size and is still maintainable. After all, it
can look almost exactly like Java.

On the other hand, it's impossible to scale Java down to the point where it
would be sensible choice for what would otherwise be a bash script.

------
ncmncm
"Again"? That seems to pre-suppose a counterfactual.

Counterfactuals can be cool, but you have to explore them, not pre-suppose
them. Pre-supposing them is definitely not cool, which calls into question the
ability of our interlocutor to recognize what is and (more pointedly) what is
not.

------
patelh
Why not just use Scala, you get all of that out of the box, no need for
annotations, and you can still maven ;-)

------
malcolmgreaves
IMO just move to Scala: the change in thinking from mutable, stateful OO to
immutable, pure FP (w/ some side effects mindfully mixed-in) is indeed steep.
However, accepting this paradigm shift yields unbelievable dividends in terms
of quickly writing correct programs that solve complex problems.

~~~
calvinmorrison
Maybe you just nailed it on the head for me what I've been trying to state for
a while in regards to FP. Expressing complex things like algorithms in
functional programming can be beautiful and also incredible in how it adjusts
your thinking. Fact of the matter is, I don't solve many complex problems like
this. It makes doing tutorials and books fun but when i need to get work i
stick to my usual guns

------
jimmcslim
Something like this would be handy for the .NET framework.

Off the top of my head; PostSharp (although not free) would get you much of
this. Also might be achieveable via Roslyn? And there is another .NET AOP
framework whose name eludes me at the moment... EDIT: Fody.

------
haglin
Data Classes for Java
[https://cr.openjdk.java.net/~briangoetz/amber/datum.html](https://cr.openjdk.java.net/~briangoetz/amber/datum.html)

------
rienbdj
I spent considerable time playing with Java and various usability extensions,
but if I could go back I would have ditched Java much sooner. ML based
languages really are an order of magnitude productivity boost.

~~~
jimbokun
"ML based languages really are an order of magnitude productivity boost."

Is this still true when you consider available libraries, performance,
concurrency, build and dependency tools, development environments, and
deployment options?

~~~
rpeden
I'd say it depends on which ML derivative you're talking about.

I've found F# to be pretty good in all of the areas you mentioned. Although
not enough to literally provide an order or magnitude boost like the post you
were replying to suggested.

I think people use "order of magnitude" a little too freely. Developing with
Java (and to a lesser extent, C#) _feels_ slower than with F#, but not 10
times slower.

~~~
rienbdj
I was not exaggerating, although you would not see the same improvements for
all applications. The big win for me is do notation (or computation
expressions). I hate to think how I would even write complex async code
without it. If I was only writing something linear then Java wouldnt be so
bad.

------
JohnHaugeland
Have you ever noticed how these "cool again" posts always seem to come from
companies with billions of dollars that struggle to make their sites work
under relatively low load?

Five times in six their grocery search - literally the core of their product -
502s on me. In the remaining 1 of 6, if I just keep repeating, I get random
subsets of the data I should actually be getting. It's amazing to me that I
haven't seen a fail whale yet.

I refuse to believe that Instacart has a large practical server load.

These are not the people we should be listening to.

~~~
RandallBrown
This is from Grubhub, not Instacart.

------
zmmmmm
Even cooler is using a JVM language that builds many of these features in (my
favorite is Groovy). Java will always be weighed down by the (necessary)
baggage of backwards compatibility. I think companies still confining
themselves to strictly using Java and nothing else are doing themselves a
disservice when there are JVM languages that offer almost perfect
compatibility at the bytecode level.

------
Kiro
Why do you need to write all these getters and setters? Why not just a public
property?

------
stevehiehn
Not sure I agree with the claim considering Lomboks been around for quite a
long time.

------
jillesvangurp
I've used lombok in the past but only in projects where somebody insisted on
using it before I joined. It can be nice having it around if you are stuck in
a project where you have to use Java and it's just not negotiable to use
something else and you have to use frameworks that expect a lot of model
classes, DTO's and so on that comply with the java beans convention.

This is a convention that emerged in the late nineties where people used a
naming convention for setters and getters to expose properties. Lots of
frameworks (hibernate, jackson, gson, etc.) rely on discovering such
properties via reflection. Unfortunately this results in a lot of boiler plate
and code that does nothing interesting. Worse, a lot of these frameworks
expect mutable classes, which should rightfully make you feel dirty every time
you write one.

Lombok helps with that and you can sort of fake having quasi immutable
classes. There's a price to pay unfortunately: it depends on generating code
at compile time. This makes it necessary to use plugins for your favorite IDE
to not get confused about all the non existent methods you are calling to
access these getters, setters, builders and all the other boiler plate Lombok
generates. Unfortunately these plugins make intellij more likely to get
confused, which is something that can only be fixed with lengthy rebuilds,
cache clearing, and the occasional restart. I've wasted no small amounts of
time in trying to convince Intellij to get rid of phantom compile errors.

For this reason, I'd never introduce it in any project I'm in charge off. It's
just not worth the pain and I'd rather solve the problem of not having to have
stupid code like that to begin with by using something that does not require
it. IMHO code generation is a bit of an anti pattern. It's kludge for having
flawed languages and broken frameworks. There usually is a better solution
than generating a lot of source code.

These days, Kotlin is a vastly superior way (and I say that with close to 25
years of Java experience) of avoiding that type of code and modern frameworks
like spring boot work fine with it. Also worth pointing out that Java is
slowly absorbing new features. Type inference is there now and they are
working on data classes and a few other features. It might eventually catch up
with less than half of what Kotlin does today in a decade or so. But why wait?
IMHO Java is no longer a defensible choice on most new projects.

Converting Java to Kotlin with the built in conversion tool in intellij is not
flawless but it gets you quite far and you can go class by class. I actually
have one project where I've been gradually moving to Kotlin for over a year
now. Every time I touch some old code, the first thing I do is convert it to
Kotlin. Only takes a few minutes once you get the hang of it and it's a great
way to explore the language. Mostly you spend this cleaning up the things it
got wrong regarding nullability, funky generics, or just using a bit more
idiomatic constructs (e.g. using sequences instead of streams), etc .

------
jkmcf
Somewhat serious: LombokScript please.

To quote @Retra in this thread: "I feel it is important for writing code to be
fun". IMO, programming is fun when you are solving "business" problems, not
writing boilerplate or handling a language's myriad edge cases.

~~~
zmmmmm
I kind of agree, but I also find it curiously self-indulgent that as a
profession software engineers feel entitled to discard technologies and
methodologies because they are "not fun". Can you imagine civil engineers or
electrical engineers saying that? They might enjoy working with certain
technologies but would consider it highly unprofessional to demand that their
projects be "fun" over other considerations.

NB: Groovy might be the closest thing to "LombokScript"

------
agumonkey
pythonistic coffeescript for java ?

------
throwmeback
Just switch to C# already.

/s (just a bit)

------
foobar_
It is practically impossible to teach good programming to students that have
had a prior exposure to JAVA: as potential programmers they are mentally
mutilated beyond hope of regeneration.

------
benbenolson
One of the major features of a language is its syntax-- and here, it seems as
if the author, instead of simply using another language, is "fixing" Java's
verbosity by installing a compiler pass that converts "shorthand" Java into
valid Java code. Why wouldn't the author just use another language?

~~~
esrauch
Sometimes just fixing the rough edges with syntactic sugar can provide a lot
of value. Like, CoffeeScript got pretty far with that strategy.

Honestly, a lot of the best TypeScript features could be described the way you
describe it.

