In case anyone is wondering if this signals a shift away from Go in container infrastructure, I don't think so. Docker, Kubernetes, Buildah and Podman are mostly Go code and I don't think there's much intent to change that.
I suspect the conclusion (that Go is not ideal for this kind of low level component) is accurate. OTOH, I wish it could be a memory-safe language instead of C. I can only assume there is some decent reason why Rust isn't used here, though personally I wouldn't know.
It's dangerous to treat rust like a panacea. _safe_ rust is memory safe. The problem is that for most nontrivial programs (especially very low level ones), you are forced to use unsafe rust. Just look at how many times the unsafe keyword is used in the rust stdlib.
It’s not treating rust as a panacea, it’s that the ambient level of expectations for software is getting higher. Although C is going to be more ubiquitous than Rust for the foreseeable future, adding new code in memory unsafe languages will eventually require some justification as to why it’s worth the risk. We’re not there yet, but it’s coming.
And yes. Low level code requires unsafety sometimes, or at least code that is not provably safe (digression: save for maybe using actual proofs a la seL4?) The important bit about Rust and other memory safe languages is that in Rust, memory unsafeness can be minimized and accounted for. That’s a whole class of bugs that is traditionally basically unmanageable in most non-trivial projects.
Go is also memory safe by default, but the runtime is too heavy, and thus we’re here.
Early PHP was a terrible language that people nonetheless built a ton of cool things with, for a variety of ergonomic and social reasons that are not that easy to pin down exactly.
One reason is that people with ideas and a drive to implement them are often not experienced developers. They have a product mentality, and see the need to implement things in code as a nuisance that stands between them and their idea. So they pick the easiest, lowest-hanging tool, not the sharpest or cleanest.
In the container context, the Go runtime gets in the way of namespace control; 'Docker' as in RunC uses C to work around this (last time I looked) and so is compiled with cgo. I'm not sure that the direct creation/control of a container is possible using just Go. I would love to be out of date and wrong!?
More generally C is just adding some conventions, like 'calling' that can be interacted with by following the rules from e.g assembly or a higher level language that can compile to compatible calls.
Golang is great for small code bases, in a UNIX world where each program do only one thing, this is perfectly fine.
But once the code base grows, it easily becomes a tangled mess.
My biggest con for Go would be the project directory structure. At the toplevel of a project, I like to have only "src", "tests", "docs", "examples" and eventually "containers" if I provide Docker images. With go, it seems that everything should be at the toplevel (or maybe I haven't seen nicely structured projects yet?).
You can store Go files in src/ if you really want, nothing really stopping you, but it's not the usual approach, no. Tests are usually stored next to the actual implementations rather than a tests/ directory.
In which directory to store files is an incredibly small and minor detail though.
> nothing really stopping you, but it's not the usual approach
In my experience, if you open-source a project, it better have to follow conventions. Following conventions makes sure someone else can read your code easily.
> In which directory to store files is an incredibly small and minor detail though.
Yeah it's a small detail, but it is important to me to not get lost in a directory tree.
Could this be an issue with Go's built in build system rather than go the language ? At work I use go with Bazel and found it okay with regard to source layout, similar to my experience with c++. I don't have experience with go outside of Bazel though.
When I try to decide if i want to use a language, I look at its ecosystem.
It may have the best features in the world, but if the ecosystem is not there, it will be a pain to use it.
On the opposite, a language can have the worst features and a great ecosystem, for example Python is slow but as great scientific tools, or Javascript has a weird "typing system" but has tons of tools in every domain to make the best of it.
I don't know Bazel though, I'll take a look at it, thanks!
Sure, but we are talking about a single threaded program that is not doing crazy data processing at all. I'm all for Rust but there is a fairly steep learning curve.
I'm not sure I understand. Lots of single threaded programs that don't do crazy data processing have serious security vulnerabilities that memory safety would have prevented.
This is pretty great. Ideally, whoever maintains the OCI specs would have a way of allowing implementations to be “certified compliant” by an open process (maybe a suite of automated tests that the implementation must pass).
I guess this is the closest to be "certified compliant", but that is not enough for working with existing container engines as everyone just assumes runc is used
I would assume Crun is straightforwardly "Container run" with a slight bit of play on Runc (which presumably means "Run container") to emphasize that it is instead, written in C.
Given that this is an internal program name and not a product name, and that it is actually a pretty descriptive name terseness aside, I really don't see how it is so bad. Even many advanced users may never see this project name, and if they do, it will probably be in the context of being the process that actually runs their containers, in which case it should be pretty obvious.
I suspect the conclusion (that Go is not ideal for this kind of low level component) is accurate. OTOH, I wish it could be a memory-safe language instead of C. I can only assume there is some decent reason why Rust isn't used here, though personally I wouldn't know.