I would say in this case it's more the API designers' fault than Go's fault. Looks like the Python API is operating at a higher abstraction level than the Go API - using the Python API you can just call a "macro" that does everything required, in Go you have to call each operation individually.

It probably is Go's propensity to return error values whereas Python would bubble them up. Every action in Docker involves an I/O error at a minimum (since you're talking to the Docker daemon) so this is basically a worst-case scenario for error handling boilerplate. I don't doubt that Python is better for scripting in this case, but if you want to make an application that interfaces with Docker, Go is probably the better of the two (despite its boilerplate). In fact, I vaguely recall running into a bunch of Python-related bugs in docker-compose (it was at an old gig, and I haven't used docker-compose since, so I don't recall the particulars).

Still, creating a method that calls several other methods one after another is programming 101, so I refuse to entertain the though that creating a "containers.run" method similar to the one from the Python API is not possible in Go. The error handling is definitely not the culprit, you can check the error after each "subcommand" and return early with this error. The question is just, why didn't they do it?

Fair enough. I didn't look deeply at the API differences.

Wow. That's quite something. I like Go, but more often than not I keep stumbling upong these kind of situations (N LOC to do something in Y, 10xN to do it in Go).

In addition to a emulating certain teachers dogged insistence of making sure students can't have nice things (an absolute no-brainer feature like generics only showed up recently...!), last time I tried to use Go for a web project a few years ago I was also amused by the lack of templating libraries - the way to make pages was to string together header + main + footer, the old PHP way...! Not a single library supported template composition.

Umm... what are you even talking about?

Go has had templating built into the standard library since... forever?

And Go templates can use other templates, as long as they're all loaded into the same context, if that's what you were getting at.

simple examples of Go's built-in templates: https://gowebexamples.com/templates/

templates using other templates: https://levelup.gitconnected.com/using-go-templates-for-effe...

I've found Go's templating to be pretty great

That doesn't look too bad on a quick glance, but the possibility to say that "this content goes in that template" still seems to be missing.

Look at this page: https://quarkus.io/guides/qute-reference

and read about “Template inheritance” in 3.5.6 to see what I mean.

In this example, I'm passing an object with a single value into the header template, but it could have as many values in it as needed: https://go.dev/play/p/kC8pm4Z4WrH

Go doesn't really do template inheritance in the way I think you're meaning. Go prefers composition over inheritance, and that carries over to the templating system. Go templates let you pass a parameter to the template you're calling, which I believe addresses the need you linked to. Calling another template is not just simple string concatenation; the other template can act on input provided by the calling template.

There are a lot of different ways to approach templating pages in a web app. I think Go's templating system is one of the least objectionable ones I've used.

I have no experience with Quarkus, so I can't say how good or bad that one is, but my experience with Ruby templating systems is that people often start mixing complex logic into the templates, including database calls, and that causes things to get messy. Go's template environment is very minimal by default, and you can extend it with custom functions if you want to give more power to the templates, but Go encourages you to compute your data ahead of time, then pass it into the template... and just have your template be a template for formatting the data.

> people often start mixing complex logic into the templates, including database calls

Sometimes you can solve social problems with technical interventions, but at this point, someone needs to sit down and talk :-)

> Go encourages you to compute your data ahead of time, then pass it into the template

Same elsewhere including modern PHP and Java.

The thing that is missing in Go is a natural way to group together what goes around the content.

Sure, stringing together the templates (yes, I know the other template can act on input provided by the calling template, but they are still stringed together) feels weird when what one really wants is to fill in slots in a design, which is my thought process.

Event the C# version is simpler :D

https://github.com/dotnet/Docker.DotNet#example-create-a-con...

Exactly this, in rust it will even more complicated than in Go