5 ms·

OT: Not a Go dev here but have some side projects written in it... Isn't docker for Go a bit unorthodox? I had a few nice headaches setting up my local env to u

by L_226 5y ago

OT: Not a Go dev here but have some side projects written in it... Isn't docker for Go a bit unorthodox? I had a few nice headaches setting up my local env to use docker with Go to mirror my python workflow (all projects have a Dockerfile, no dependencies installed locally). I was under the impression that Pro Go people do not use docker for local Go dev. Please correct me if I am wrong.

doctor_eval 5y ago
Docker and go work fine together but using docker for go dev is just an unnecessary hassle, especially if (like me) you’re doing dev in MacOS - you have to cross compile to Linux which is slower, and then build and deploy the container - versus the very quick compile-run cycle of regular Go. 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.
- pjmlp 5y ago
  As not yet reformed Java developer, an Uberjar, custom runtime with jlink, or one the AOT compilers available, do the job just as well.
  - doctor_eval 5y ago
    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.
    - pjmlp 5y ago
      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.
      - doctor_eval 5y ago
        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 :)
        pjmlp 5y ago
        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.
adamcstephens 5y ago
I agree that adding docker to a Go dev setup is not worth it, but I think commenter was asking for a docker image for running it. In that case, I’d say that docker could be worth it for the end user.
_wldu 5y ago
I dockerize Go apps to run in AWS ECS Fargate, but otherwise I agree. Go apps don't need docker.
physicles 5y ago
Go doesn’t benefit as much from docker, but if you’re already living in a docker world (i.e. everything you deploy is a docker image, and it’s managed by compose or kubernetes) then it’s easier to use docker than not. 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.

by L_226 5y ago

doctor_eval 5y ago

Docker and go work fine together but using docker for go dev is just an unnecessary hassle, especially if (like me) you’re doing dev in MacOS - you have to cross compile to Linux which is slower, and then build and deploy the container - versus the very quick compile-run cycle of regular Go. 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.

pjmlp 5y ago
As not yet reformed Java developer, an Uberjar, custom runtime with jlink, or one the AOT compilers available, do the job just as well.
- doctor_eval 5y ago
  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.
  - pjmlp 5y ago
    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.
    - doctor_eval 5y ago
      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 :)
      - pjmlp 5y ago
        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.

adamcstephens 5y ago

I agree that adding docker to a Go dev setup is not worth it, but I think commenter was asking for a docker image for running it. In that case, I’d say that docker could be worth it for the end user.

_wldu 5y ago

I dockerize Go apps to run in AWS ECS Fargate, but otherwise I agree. Go apps don't need docker.

physicles 5y ago

Go doesn’t benefit as much from docker, but if you’re already living in a docker world (i.e. everything you deploy is a docker image, and it’s managed by compose or kubernetes) then it’s easier to use docker than not. 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.