Docker didn't have much of a choice. At the time they had two options: C/C++ or Go (Rust wasn't usable at). They went with the right choice at the time, Go. Unfortunately nobody really knew about all of the pitfalls of Go (there are many upsides, but writing a container runtime in Go is definitely not one of them).

Right now, I would definitely recommend people write things like this in Rust. In fact I was planning on working on something similar. :P

Sure, in that case, some Rust expert should write an article detailing all these Go pitfalls related to syscalls at kernel level :P

I'm not a Rust expert (yet) but I probably should write something up because this topic always comes up when people like me start complaining about Go.

Author here. As I mentioned in another comment. I should have clarified that its shortcomings are specific to the container runtime (i.e. the part that creates and enters the namespaces). Go is a great choice for the command line utilities and daemons. I am a big fan of go in general, and even the container builder smith is written in go.

Don't generalize from this post. That's a trap. Go's runtime model doesn't interact well with stateful namespace syscalls in the Linux kernel, and it's hard to fix. That's all that can be concluded.

We've had production issues where Go's memory model will cause programs such as dockerd to crash due to overzealous memory over-commitment (Go doesn't actually free memory they use MADV_DONTNEED). There are definitely problems with Go that go outside of "stateful namespace syscalls".

I meant specific to this issue given Oracle's wording in the post (and am not disagreeing with you).

Go could be in the same space as Oberon was for systems programming (real OS stuff and bare metal coding), but for that to happen they would need to improve the runtime and unsafe package for those scenarios.