[cgh]

Java is hugely popular and widely used on large backend systems. I guess a lot of people here don't work on such systems? I'm always surprised when I see comments like the parent, since in my career exposure to Java is near-ubiquitous.

[Noe2097]

There has been a move in the past 8 years away from Java on the back end, notably to Go, by several large engineering organizations, which made the move, "motivated" by the example of companies like Google or by projects like Kubernetes, and seduced by the promises of a language simple to learn, build, and deploy.

[p2detar]

> seduced by the promises of a language simple to learn, build, and deploy

That's actually quite correct and I'm saying this as someone that does Java on daily basis. Go is in fact superior in terms of deployment. I would rather deploy a Go-written service than a Spring Boot one. That being said, I love using Java for monoliths - large code bases crammed with business logic. I personally don't see Go doing very well in that direction.

[Tostino]

What deployment challenges have you had with Java / spring boot apps? It has been totally smooth sailing for me.

[makapuf]

Why is it so ? Is go specifically lacking somewhere ?

[lenkite]

Businesses often deal with old databases, message queues, SOAP services, legacy systems. Java has a truckload of well-established connectors (Even more than Python!), well-supported JDBC drivers, and vendor-supported SDKs.

Also features like transaction management, dependency injection, validation frameworks, AOP-style cross-cutting concerns are better addressed in Java.

Java has collection streams with great customizability (filter/map/reduce/etc). Far better writing your 10,000th for-loop in Go. You can also get automatic parallel streams without writing any extra code.

Go's profiling tools (esp memory) are very primitive, sorry. JVM profiling tools beat Go's by orders of magnitude. So does the other tooling - GC tuning, monitoring, etc. Java flight recorder and VisualVM are gorgeous.

That said, Go is still better at memory efficient, tight network software like lean k8s controllers. Though frankly, Rust is encroaching into this space.

[mdaniel]

I'm not them, but there are few things better for operational insight than the JVM. It has a boatload of tuneables, it has a very rich dynamic code load mechanism (Reflection, ClassLoaders, the new Modules system, and it used to have a strong sandboxing system but they killed that), and at the intersection of those two things is JMX, which is dynamically tuneable deployments via API. It's like having JVM-local feature-flags that one can twiddle without needing to bring down the JVM

And sure, it's not everyone's cup of tea, and/or plenty of people will chime in with "yes, but"s to defend golang or every other platform that isn't the JVM. I'm not yucking your yum! I'm just saying for me, the JVM is the bees knees

[Quekid5]

Go is slowly becoming Java 1.5+ -- see the addition of generics.

Btw, you can AOT compile Java if you wish... it'll probably be a larger binary than a Go binary, but that's whatever...

[Meta] ... God, I'm turning in pjlmp here, lol

[kccqzy]

Creators of Go within Google conveniently left out the fact that within Google there's still far more Java code than Go code.

[re-thc]

> by several large engineering organizations, which made the move

The problem with this type of trend is it's often hype and you never know what actually happens or how does it evolve over time.

I've seen organizations make certain announcements, switch maybe 5%, give up and go in different directions, but only the initial announcement ever hit the news.

> and seduced by the promises of a language simple to learn, build, and deploy

It's always simple if you rip it all up. Nice and shiny toys are always great.

[belter]

Most of the largest cloud was built on Java....

[SoKamil]

I suppose we are talking about user-facing desktop software.

[lisbbb]

I think the rise of containers and being able to compile and run natively has eliminated the argument that would favor the JVM. It's so easy to fully control your dev and deployment environments now using Docker images and to me, that's a far better solution. tl;dr -- containers eliminate Java long term.

[re-thc]

> tl;dr -- containers eliminate Java long term

Why can't they co-exist?

> has eliminated the argument that would favor the JVM

This complaint is taking technology definitions too literally. I doubt new adopters of Java or the JVM are really going on about that now. It's more been about the ecosystem, the maturity, etc.