You can pretty much replace "docker build" with "go build".

But as long as people want to use scripting languages (like php, python etc) i guess docker is the neccessary evil.

Go is just one language, while Dockerfile gives you access to the whole universe with myriads of tools and options from early 1970s and up to the future. I don't know how you can compare or even "replace" Docker with Go; they belong to different categories.

>You can pretty much replace "docker build" with "go build".

I'll tell that to my CI runner, how easy is it for Go to download the Android SDK and to run Gradle? Can I also `go sonarqube` and `go run-my-pullrequest-verifications` ? Or are you also going to tell me that I can replace that with a shitty set of github actions ?

I'll also tell Microsoft they should update the C# definition to mark it down as a scripting language. And to actually give up on the whole language, why would they do anything when they could tell every developer to write if err != nil instead

Just because you have an extremely narrow view of the field doesn't mean it's the only thing that matters.

In some situations, yes, others no. For instance if you want to control memory or cpu using a container makes sense (unless you want to use cgroups directly). Also if running Kubernetes a container is needed.

You have to differentiate container images, and "runtime" containers. You can have the former without the latter, and vice versa. They are entirely orthogonal things.

E.g. systemd exposes a lot of resource control as well as sandboxing options, to the point that I would argue that systemd services can be very similar to "traditional" runtime containers, without any image involved.

> You can pretty much replace "docker build" with "go build".

Interesting. How does go build my python app?

Wasn’t this the same argument for .jar files?

It doesn't sound like Golang is going to dominate and replace everything else, so Docker is there to stay.