> so writing a unikernel like this allows you to select exactly as much as you need for your particular service.

I agree this is a big upside of the authors approach. Less dependencies lead to fewer problems caused by external/upstream changes.

> OCaml isn't all that much slower than C++. To use the Programming Language Shootout as a rough esimation[^1], it can even come close to matching C++ in certain programs, and is rarely more than three times as slow.

I wasn't only referring to raw execution performance but also to GC pauses and GC overhead which I think are the bigger issue. The benchmark you linked tests for compute load so this doesn't really show up. Anecdotal point; in most real world apps I have worked on the GC was a limiting factor.

> Finally: the article didn't say, "the Linux kernel"—it said, "Ubuntu." The kernel itself might be secure and reliable, but a running Linux system is much, much more than just the kernel.

That's the beauty of having a kernel though. If one of those userland processes is broken it won't affect the whole system.

> an arbitrary piece of C code might not segfault given certain input, but a given piece of OCaml code definitely won't.

This assumes that the OCaml compiler/interpreter and the hardware are free of bugs...