3 ms·

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 don

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-mix https://www.weave.works/blog/linux-namespaces-and-go-don-t-m... [1]: https://github.com/drahnr/railcar https://github.com/drahnr/railcar

SEJeff 6y ago
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 6y ago
  Or they want to be more platform-agnostic than rust and llvm.
  - coder543 6y ago
    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 6y ago
      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.
deleted 6y ago
[deleted]
xyzzy_plugh 6y ago
> 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/2595fe7fb6f272f9204ca3ef0b0c55e66fb8d90f https://github.com/golang/go/commit/2595fe7fb6f272f9204ca3ef...
- vishvananda 6y ago
  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/libcontainer/nsenter https://github.com/opencontainers/runc/tree/master/libcontai...
  - BenTheElder 6y ago
    this seems like a pretty trivial amount of C, by comparison, and a pretty solved problem now.

SEJeff 6y ago

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 6y ago
Or they want to be more platform-agnostic than rust and llvm.
- coder543 6y ago
  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 6y ago
    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.

deleted 6y ago

[deleted]

xyzzy_plugh 6y ago

> 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/2595fe7fb6f272f9204ca3ef0b0c55e66fb8d90f https://github.com/golang/go/commit/2595fe7fb6f272f9204ca3ef...

vishvananda 6y ago
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/libcontainer/nsenter https://github.com/opencontainers/runc/tree/master/libcontai...
- BenTheElder 6y ago
  this seems like a pretty trivial amount of C, by comparison, and a pretty solved problem now.