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.
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.
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?).
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!
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.
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.
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.
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.
Every day I wake up full of hope thinking, "coders couldn't possibly come up with a project name any worse than what I've already seen." Today I was yet again disappointed.
Is there a wikipedia article about this? The phenomena where coders come up with the worst names ever? I actually parodied it by naming my compiler C-, alternatively written as cmin, and pronounced "semen". I challenge my fellow coders to come up with a worse sounding project name.
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.
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
46 comments
[ 8.9 ms ] story [ 397 ms ] threadI 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.
Personally I'd prefer people didn't use golang not because of speed but because it's a terrible programming language.
It's a surprisingly divisive language. Go users seem to mostly be happy cranking stuff out but a lot of people hate it.
No generics, a culture of "if err != nil", type system not powerful enough, libraries not pure enough, too verbose, etc.
Sure I can code full applications in GW-BASIC or whatever programming language of similar age, and did, almost 40 years ago.
It doesn't mean I enjoy doing them today, beyond some nostalgic weekend hobby.
Then again, assuming that generics proposal doesn't end the same way as the error one, it won't be that bad.
Go will finally feel like using CLU (from 1975).
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.
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?).
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!
In which directory to store files is an incredibly small and minor detail though.
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.
Random example taken from a github search: https://github.com/gofiber/fiber
Is it really ok to have that much source code at the toplevel? Is the code architecture clear at a glance?
For me, it is not, and I'll have to put in extra work (I'm lazy) to understand the code and how it works.
I don't mind doing that for other projects, but for my projects as I work on them daily, it becomes a pain very quickly.
https://github.com/golang-standards/project-layout
Naturally C doesn't need bindings, when the OS APIs are written in C.
The distinction I was attempting to make is whether or not C source code is required in your Go project to fully implement a container runtime.
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.
- Uses all the static analysers it can get hold of
- Pursues a policy of zero warnings
- Has fuzzing as part of the CI/CD process
I just opened a ticket requesting clarification.
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.
Is there a wikipedia article about this? The phenomena where coders come up with the worst names ever? I actually parodied it by naming my compiler C-, alternatively written as cmin, and pronounced "semen". I challenge my fellow coders to come up with a worse sounding project name.
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.
In retrospect, I could have chosen a better one.
I thought the naming was bad because OCI is currently associated with Oracle cloud - but your critique was far better!!!
The tests are maintained here: https://github.com/opencontainers/runtime-tools/tree/master/...
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
https://en.wikipedia.org/wiki/Henry_Crun_and_Minnie_Banniste...