As a reformed Java developer I can say that docker didn’t add much time to the build cycle and gave us a better way to package resources for Java code, but Go is far more ergonomic, so taking a <2 second compile time for a small microservice and adding docker to turn it into a 30 second build time just isn’t worth whatever utility you get from containers at dev time.
Docker helps manage all of this, and does it fairly quickly, and made life relatively easy, but not without a cost in time and complexity.
Go, out of the box, produces statically linked machine runnable binaries, including embedded resources, so you get the equivalent of an uberjar, plus resources, plus the runtime, all in a single executable file. And all of this pops out in a second or two with `go build`.
AOT for Java might perhaps have similar advantages except that AFAIK (two years ago) the AOT compilers were expensive and had plenty of caveats with eg reflection. I expect they would be even slower than javac as well. So certainly a solution, and maybe you don’t need docker any more, but then you have a different set of problems. It was never feasible when I was doing Java.
To be clear, this isn’t a Java vs Go thing. The question was why don’t Go devs use Docker, and I’ve given some reasons. I quite like the Java language and miss some aspects of it, but there is a lot about the Java environment that I don’t miss and runtime deployment complexity is one of them.
I never been into US, plus the restrictions apply to any tech produced in US, regardless of the programming language.
Thankfully, by having such laws, US made us create other standards as well.
I also don't want to make it into a Java vs Go thing, rather make the point that many dismiss Java without really knowing what is around during the last 26 years on the ecosystem.
It appears everyone just learns the basics and then complains from there.
Not targeted at you, as you obviously got my point.
On the other hand, kubernetes and docker are all about runtime deployment complexity. It feels like using Websphere 5 all over again, with containers == EAR, thankfully so far I managed to stay mostly away from them.
Re the export restrictions, although you are right in theory, it doesn’t seem to affect Go. There is no special build, the crypto is just built in. Java is unique in how it dealt with this, I never understood why it was so hard.
I agree with you re K8s. And I like the comparison to EARs. Both container systems are pretty poor substitutes for a binary you can just run in an OS.
Go seems to recognise this. It knows its place in the deployment hierarchy and that’s made my life so much easier. Go feels like it’s part of the Unix world, rather than apart from it, and Java was never like that. That’s why docker became so important in the Java world. It gave Java the isolation from the OS that it always craved :)
Ask the developers on countries with blocked access due to US sanctions how they get to use Go without workarounds.
Go was written by two of UNIX people as better C, not as a cross platform tool. In fact there are still language features missing from Windows support.
Java always felt at home in Solaris thought.
Docker isn't that relevant on my Java projects, it is only used in projects where customers want to feel modern or already have it as part of their workflow regardless of the technology stack.
I am pretty much 99% of the time on VM + scripting world.
We build images (about 20, each with a Dockerfile) from a monorepo with a single go.mod. I have basically a full replica of prod running locally in k3s — letting k3s manage it all is easier than dealing with the pile of environment variables that would be needed to get everything hooked up properly. And with kustomize, we can reuse a bunch of yaml from prod.
Sometimes I’ll run go binaries locally on my machine for debugging (the builds still work because go’s packaging is finally stable). But the difference is minimal — using docker/k8s is more about streamlining deployment/config/rollback (and the occasional co-packaged asset) than anything else.