[alkonaut]

> If someone is willing to throw a few hundred million or so at re-building an operating system from the ground up that is 100% safe and reliable and that does not have more bugs than what is available right now then they are free to do so.

But at the same time - we are spending those billions. We keep throwing billions at Apple by buying their new phones, yet they release lists of security issues which this time were basically all:

  - malicious crafted image -> remote code execution

  - maliciously crafted font -> remote code execution

  - maliciously crafted audio -> remote code execution

I'm not sure if I have to be able to write a font parser and rendering subsystem in a memory safe language myself to be allowed to complain that Apple is using my money for something other than doing just that. To me it's completely mind blowing that someone uses a C library to parse complex third party binary data from the internet.

[mirekrusin]

If c lib is mind-blowing, what about kernel and it's extensions?

For now c is the only thing we have that can be used so widely. Some day we may be able to use rust or something else, but that's future, not present.

[alkonaut]

Any lang that easily calls C and can be called by C, or can be compiled to C should be fine to use today.

Re: kernel - it's a lot of pretty simple subsystems. Each system is usually simpler (easier to verify and polish) than a lot of common libs doing really complex things (ssl, video codecs, ttf, ...). Complexity + raw pointers quickly add up to guaranteed problems.

Rust uses llvm. Use it for new development on any platform that llvm supports. A few microcontrollers might be left out.

[steveklabnik]

Rust can speak C's ABI, so you can write kernel extensions in Rust. There's some legwork involved, but it's quite possible.

[mirekrusin]

Interesting.

So you're saying that Rust, at the moment, in theory, can be used in any place where C is required? Ie. writing kext on macOS, loadable kernel module on Linux or things like extension for SQLite are all possible?

In that case I wonder if there are any theoretical blockers for things like (using no_std and) mapping internally used C structures (let's say BSD kernel's rbtree) into typed, first-class Rust citizens - to avoid std overhead and reuse what's already available? In other words - is there anything there in C macros that can't effectively be expressed in Rust for example?

[steveklabnik]

That's correct.

There are no theoretical blockers; tooling could make it a lot easier though. I was hand-porting chunks of the Ruby interpreter, which uses C macros extensively, and it's doable, but not fun.