If someone asked me that question 3-4 years ago, I would have likely said Java. At that point in my career, I spent some solid fifteen years building enterprise applications in Java, and I was perfectly happy with it.
In the past three years, I have been doing more and more of my work in Golang. If I had to pick a language for backend microservice development (which is where 99% of my career has been), I would now gladly choose Go.
Cross-platform nature of Java has not been relevant for at least a decade now
Java’s biggest selling point used to be platform independence: “Write once, run anywhere.” The reality is that in my career, I don’t think I ever needed to run my software on anything other than a Linux x86 server.
The problem of portability has long been solved by containers, like Docker. Therefore, it is no longer relevant for compilers to produce cross-platform bytecode and require a complex virtual machine to run it.
Pointers aren’t that complicated
Developers have been building applications in Objective-C for iOS, and pointers have never been an issue. In Java, just about everything is referenced via pointers. The real problem with pointers is knowing when to deallocate memory.
Java solves it with a complex and resource-intensive garbage collection mechanism. Go also relies on garbage collection, but optimizes it for low latency.
Concurrency in Java has become too bloated with too many ways to shoot oneself in the foot
Go concurrency is vastly simpler than Java yet more flexible than the Node.js model.
Back in the 1990s, Java supported the concept of “green threads,” but they were ridiculously inefficient. The community was ecstatic when Java began to support native operating system threads.
Go does green threads far more efficiently, resulting in much better utilization of multi-core servers.
Object orientation isn’t that critical
Go is not object-oriented. In practice, there is rarely a reason to use more than three layers of inheritance.
Despite not being object-oriented, Go supports inheritance by composition, which is good enough for most projects.
Deployment package size matters
Large deployable packages are costly when used with modern-day containers and serverless functions. Large containers take longer to bootstrap, longer to build, longer to deploy. Large functions have long wake up times and may not work at all as they exceed the maximum footprint enforced by the cloud provider.
Go, on the other hand, is statically linked and produces a single executable binary all dependencies in it. A complex application can be no more than a few megabytes in size. It is quick to start, ready to run, and exerts little pressure on computing resources.
There is little reason not to use Go for a brand new application, or brand new services for an existing application. It’s a platform ideal for cloud-native applications due to its compactness and efficiency.