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