Ask HN: Go vs. Python (Docker SDK) | Hacker News Reader

Ask HN: Go vs. Python (Docker SDK)

20 pointsdanwee10 comments

I was just reading Rust – A hard decision pays off (https://news.ycombinator.com/item?id=32578743) when I stumbled upon this comment https://news.ycombinator.com/item?id=32580654

> Docker is built with Go. Compare doing things with Docker api between Go and Python. I usually recommend people to "script" things with Go but I start to think that Go has to go... https://docs.docker.com/engine/api/sdk/examples/

The very first example of the SDK page is quite a shock. To "run a container" in Python is 3 LOC. To do the same in Go takes 56 LOC. But why? I can imagine one could add a simple method to the Go SDK to mimic what the Python SDK is doing, but that's not the case. So, why this huge difference? One solution is "Pythonic" and the other is "the gopher way"?

View on HN

Go is not predisposed to write terse code. This is a feature, built into the language design. And it's great when working with a team of people with a wide variety of skill levels, but it's explicitly not a code golf language.

I know plenty of Go libraries that do feel terse when using them (e.g., the stdlib to begin with). I know plenty of Go libraries that feel overcomplicated (but I think it's not a fault of the Go language, but of the library designers). To put two I have been using recently:

- the Docker SDK for Go

- aws-sdk

What is the best Go SDK examples for you?

If your goal is to minimize lines of code, sure, Python takes the cake here.

But here's a different way of looking at it: using only Python example, can you identify every way that launching that container might fail?

Now do the same with the Go example. See the difference? Folks who value looking at a piece of code and knowing what might happen - not just in the happy path but also in the error path - I think will likely appreciate the Go sample.

In this specific example, I can't imagine how all of this exposed plumbing and error handling adds much value for the person reading or writing the code. In fairness, however, the Go code could easily be moved into function that does all of the dirty work and presents a minimal interface...which is what the Python example is doing:

https://github.com/docker/docker-py/blob/923e067dddc3d4b86e4...

Sure, but why not adding the "easy way of doing things" as well in the Go SDK? It certainly would help a lot when writing prototypes and trying things out. Later on, sure you can rely on the most robust approach (which yes, I agree, Go does seem more robust in the particular examples in the SDK page)

The best example of Go code of "knowing what might happen" is `pv_controller.go` in kubernetes, which is commented "space shuttle style", ie: "PLEASE DO NOT ATTEMPT TO SIMPLIFY THIS CODE. KEEP THE SPACE SHUTTLE FLYING." https://github.com/kubernetes/kubernetes/blob/master/pkg/con...

Major contributor to the Docker Python SDK and attempted contributor to a better Docker Go SDK here.

The Go SDK is very low level, and a lot of the high level stuff happens inside the client code in a way that is hard to extract. There was an effort to abstract that in a way that could be reused but it was never prioritized so got stuck on the backburner. I attempted to create a separate SDK that the Docker client didn't build upon, but, if I recall correctly, there wasn't much appetite to do that because then we would have to maintain two codebases and it wouldn't automatically get better when we fixed bugs/improved things in the Docker client.

Here was the prototype: https://github.com/bfirsh/docker-sdk-go

As others say here, Go code does tend to be more verbose, but the Docker Go SDK is very low level and could be higher level. It doesn't have a `Run()` function for example, and there is no technical reason why it couldn't.

Two benefits to Go:

- Installing 3rd packages such as the docker SDK easier

- Programs are more portable and easier to distribute

It’s also a lot faster, I use the python sdk regularly and it can be painfully slow

Reply on news.ycombinator.com