> 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 2 days ago | parent | next [-]

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

▲

makapuf 3 days ago | parent | prev [-]

Why is it so ? Is go specifically lacking somewhere ?

	▲	lenkite 2 days ago \| parent \| next [-]
		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 2 days ago \| parent \| prev [-]
		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