Not really. Even with an uberjar, you still need to get that huge Java runtime distributed somehow. And then you need all the command line rubbish, starting heapsize, system properties, etc. Not to forget, for those of us outside the US, a special handmade distro of Java with the crypto export restrictions file in the right spot.
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.
You missed the part of the comment, "custom runtime with jlink".
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.
I exited Java just as modules were kicking in so I’m not really familiar with jlink. But you still need to distribute that custom runtime and docker helps with that. I think docker is a great tool for dealing with Java’s complexities. A Java docker image is like a Go executable.
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 :)
In regards to restrictions, Go just flights under the radar by being on GitHub.
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.
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.