[apta]

These complaints are usually by people who have not been using modern Java, or who have just been reading or hearing unsubstantiated claims about it. Or who haven't worked in large golang projects to see all the mess it brings with it because of how underpowered it is.

Look up libraries like Spark[1] or Javalin[2] and you get something quite light weight. Or DropWizard[3] if you need something more holistic.

That being said, the moment you need something more involved, say validation, DB access, pre- or post- endpoint call processing (e.g. for authorization), then golang completely falls on its face. There is nothing in golang that compares to Jooq[4] for instance, and because golang doesn't have annotations, you can't do automatic validation or authorization, and you end up having to do everything manually in a verbose and error prone manner.

For static compilation in Java, GraalVM is supposed to be quite good[5]

[1] http://sparkjava.com/ [2] https://javalin.io/ [3] https://www.dropwizard.io/1.3.12/docs/ [4] https://www.jooq.org/ [5] https://quarkus.io/

[fileeditview]

You are right that big (especially enterprise) projects in Go are also a mess. But one of the main reasons is that people have a Java (or C++) background and try to replicate all sorts of complexity.. not because Go is "underpowered".

Also if you compare those codebases to Java (again enterprise) projects of a similar size they seem quite readable instantly..

[apta]

> You are right that big (especially enterprise) projects in Go are also a mess. But one of the main reasons is that people have a Java (or C++) background and try to replicate all sorts of complexity.. not because Go is "underpowered".

That hasn't been my experience at an employer. Their devs mainly had Python and NodeJs experience and similar languages (which is what the first version of the code base was written in), and disliked "enterprisey" code. Somehow, the decision to move to golang was made.

Yet, they somehow managed to come up with their own mess, and yes it is mainly because how underpowered golang is. I keep thinking about how much simpler the code base would be if it were written in Java, let alone something like Kotlin.

[gravypod]

I've used Spark in prod. Worked great and was the highest QPS service in the company I worked at. It was pushing >5GB/hour of JS over ~50 running containers at more than ~1000QPS/container each doing a bunch of crypto (AES) & and data wrangling (JDBC). Only thing that was difficult was serving SSL but that was the Java SSL-key ecosystem's fault. Ideally SSL would come from an edge load balancer but this company had a strange requirement that there was no 80 traffic.

[dullgiulio]

GraalVM is nowhere near production-ready nor is supported by a lot of frameworks. Porting existing code is still a big challenge.

[pdimitar]

There hasn't been a single job advert in the last decade when I was being contacted for Java gigs that didn't involve dealing with legacy code and dependency injection spaghetti.

Everybody has legacy code. Modern Java doesn't mean much if your team is 2 years away from being able to use the modern stuff.