>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.

My point was that 90% of "dockerized" stuff is just scripting langs

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.

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.

Well, I did mention "or use cgroups" above.

And what I've said is that there are more options. You don't have to use cgroups directly, there are other tools abstracting over them (e.g. systemd) that aren't also container runtimes.

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

Interesting. How does go build my python app?

It obviously means you dont use a scripting language, instead use a real langauge with a compiler.

Calling "go" a "real language" is stretching the definition quite a bit.

Real languages don't let errors go silently unnoticed.

For any serious app you dont ignore errors, and enforce them with the vast go linting tool.

Ok yeah let me just port pytorch over that should be quick

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.

At the risk of stating the obvious, there's quite a lot of languages besides just scripting languages and Go that get run in containers.