So your whole argument isn’t that crun itself is unstable but that C can be hard for non-experts to write programs in. That could be said of tons of stuff including the OS kernel you’re using to run containers, so I’d be curious to hear what you’re using to replace Linux in your work.
The principal issue with Go applications in my work continues to be the massive size of the executables.
I can't speak for crun specifically since I haven't used it personally but almost every single C application I've had to deal with had these hard to debug memory corruption bugs which required an expert (me) days/weeks to fix. And that included the Linux kernel itself btw, the difference being it was almost always fixed in the upstream by the time I found it.
> The principal issue with Go applications in my work continues to be the massive size of the executables.
That is certainly true in general case, however out of curiosity I went to see the size of containerd runtimes on my machine and:
Some systems I’ve worked in have entire root filesystems that are merely twice the size of that one binary. And in those cases sending an extra 40 megabytes over the network connection is a big imposition. So there are still places where executable size matters and that’s why we’d want crun and not runc. If someone wrote an alternative in Rust I’d be interested but golang is just too piggy.
Sure but I’m having a hard time imagining a scenario where a full blown OCI (i assume youll run it with kubelet/nomad) is required on such a constrained hardware and simple nspawn or systemd container won’t do
The principal issue with Go applications in my work continues to be the massive size of the executables.