[vishvananda]

Go is actually a really poor choice for the container runtime because much of the container setup cannot be done from multithreaded code[0], so it has to be done in C before the go runtime initializes. I do think rust is a better choice for this layer than C because there are still security risks, but getting rid of Go for this layer is a win. I'm not sure why RH chose to rewrite it in C rather than using rust[1].

[0]: https://www.weave.works/blog/linux-namespaces-and-go-don-t-m... [1]: https://github.com/drahnr/railcar

[xyzzy_plugh]

> Go is actually a really poor choice for the container runtime because much of the container setup cannot be done from multithreaded code[0]

This was addressed in 2017/2018 [0], it's no longer a poor choice.

[0]: https://github.com/golang/go/commit/2595fe7fb6f272f9204ca3ef...

[vishvananda]

While the particular issue of network namespaces and locking the os thread was fixed, there is still c code that must run before the go runtime starts to work around the issue that you cannot do some of the necessary nsenter calls once you have started additional threads. The c code to make runc work is encapsulated in libcontainer/nsenter[0]

[0]: https://github.com/opencontainers/runc/tree/master/libcontai...

[BenTheElder]

this seems like a pretty trivial amount of C, by comparison, and a pretty solved problem now.

[SEJeff]

This I entirely agree with you on but I’d expect it due to the resources available at the time were more fluent with C than rust. A shame really.

[Brian_K_White]

Or they want to be more platform-agnostic than rust and llvm.

[coder543]

Which platforms does Red Hat support Linux containers on that Rust doesn't support? Which platforms is anyone else frequently using Linux containers on that Rust doesn't support? I'm pretty sure the venn diagram here would be a single circle. Rust supports the major architectures.

Portability seems like an unlikely reason here, but I would pick memory safety over portability every single day of the week. Rust is far from the only language that offers memory safety, but it is certainly one of the most compelling ones for projects that would otherwise be written in C.

"runc" is battle tested, written almost entirely in Go, which offers memory safety, and the performance delta under discussion is only about 2x for a part of the system that seemingly only has a measurable performance impact if you're starting containers as quickly as possible.

This just isn't a very compelling use case for C.

[Brian_K_White]

Who knows? Who cares?

If I worked for RedHat I would still seek to write as portable as possible just on general principle or for the sake of my own future self.

But I agree it's merely a possible reason and may not be a major one.