"But I'm not brilliant, and I don't have a lot of energy, and so I'm also grateful there exists an operating system I can understand, and other people who continue to work to make that operating system useful."

Writing correct, efficient C takes more years to master than people take to learn Rust that I've seen. Also, the C compiler and many other parts of OpenBSD are black boxes to their developers. Your worries apply equally to their situation unless you've read and understood all their dependencies. On top of it, the OpenBSD people are always rewriting stuff for claimed benefits in maintainability or security. It's just when we talk a safe, systems language that can be as simple as a Wirth language or complex as Rust they suddenly can't justify the effort of even piecemeal replacement.

Then, next week, they'll put piles of effort into a mitigation across their toolchain whose benefits are so probabilistic even they can't tell you what attacks will fail or succeed. It's worth it, though, to improve their security standpoint. Unlike the pain of recoding even one utility in something like Rust. That's where this email draws the line.

Of course, I encourage people to do exactly what he asks every time another BS argument is raised. He's worried about drawbacks of a non-C language? Make something like Cyclone or get a Wirth language better at selectively turning off safety compiling to C w/ great C FFI. He's worried about compile times? Fix the compiler. He says utilities aren't rewritten in the better language? Rewrite them showing its advantages esp against the bug reports in OpenBSD's tracker. Just keep pounding away at the problems until he runs out of excuses to import stuff or is extra clear they simply don't like language/method X for arbitrary reasons. Regardless, you get a pile of safe utilities/modules for OpenBSD to do useful things on top of fast, safe tooling. Win, win. :)

Alternatively, contribute those ports to OS's that want to bring in best-of-breed tooling for boosting safety and security. They're usually smaller, less mature, and need all the help they can get.

My impression is that the Rust developers and community are firmly in the practical camp. They will keep plowing at Rust and its ecosystem. They will improve and optimize every nook and cranny they can find.

I wouldn't be too worried about Rust, it will have a niche at least as big as Ruby's is and IMO it will be way more entrenched since its target domain moves way slower and the barriers to entry are way higher than for scripting languages and web frameworks, IMO.

>He's worried about compile times? Fix the compiler.

If it were that simple, the compiler wouldn't be slow in the first place. Rustc and ghc have both been too slow to be usable their entire lives. There doesn't seem to be any reason to believe they can be made fast enough to consider using.

> The system being secure is a secondary benefit to it being comprehendible and coherent to an individual.

This is a really interesting and compelling philosophy to me, but it’s the first time I’ve heard OpenBSD described this way! Why is this not mentioned on the project’s homepage?

Nothing in that list says anything about being "comprehendible and coherent to an individual". I'd agree those are useful and good things, but security is indeed mentioned and emphasized there, and not as being secondary to aesthetic concerns.

As regards understandability and minimising "magic boxes", this means it's pretty much just core OpenBSD (kernel & base system). The moment you add the usual desktop environments or a huge monolith like Firefox, you've lost these benefits. Same with drivers. More drivers you have, more the system becomes byzantine. Keeping things minimal and well designed yet useful must be a continuing challenge for OpenBSD!

1) I Think Firefox is already pledged. Firefox 57 is in current, built with Rust.

2) Nothing wrong with kernel and base. It provides the kernel, clang, X.org, documentation and BSD-games, among the rest of Unix tools.

3 The drivers are in base and NOT in a module form, as the GNU/Linux crap with incompatible vendor releases and binary blobs tied to a version.

Hah. Going by the "anything you compile with a magic box becomes itself a magic box" argument, even the OpenBSD base is a magic box as soon as you run it on an x86 machine.