Regarding SQLite, here's the official tune (https://www.sqlite.org/whyc.html#why_isn_t_sqlite_coded_in_a...):

----

All that said, it is possible that SQLite might one day be recoded in Rust. Recoding SQLite in Go is unlikely since Go hates assert(). But Rust is a possibility. Some preconditions that must occur before SQLite is recoded in Rust include:

A Rust needs to mature a little more, stop changing so fast, and move further toward being old and boring.

B Rust needs to demonstrate that it can be used to create general-purpose libraries that are callable from all other programming languages.

C Rust needs to demonstrate that it can produce object code that works on obscure embedded devices, including devices that lack an operating system.

D Rust needs to pick up the necessary tooling that enables one to do 100% branch coverage testing of the compiled binaries.

E Rust needs a mechanism to recover gracefully from OOM errors.

F Rust needs to demonstrate that it can do the kinds of work that C does in SQLite without a significant speed penalty.

If you are a "rustacean" and feel that Rust already meets the preconditions listed above, and that SQLite should be recoded in Rust, then you are welcomed and encouraged to contact the SQLite developers privately and argue your case.

----

I follow the Rust story from afar, so I don't know the status of every one of these points.

B and F (FFI and speed) are covered.

C and E (embedded story and OOM recovery) is being actively worked on.

A will improve with time (for example, I suppose that the Rust 2015 dialect will settle at some point, feature-wise, once Rust 2018 is out).

D (branch coverage of compiled binaries) is on the radar, but not addressed yet.

Because C has big flaws (signed/unsigned automatic conversion, arrays without length) that Rust doesn't have. That said, you're right that I find Rust "story" that you should wrap unsafe operation behind safe APIs as something easier said than done.

Because it is a big difference to have 100% of the code unsafe or just a set of visible code regions marked as such.

Hyperbole, or do really believe every line of C is unsafe, in the literal sense, by default? Pray tell me what is the difference between

  // safe, tested, C
  ...
  // potentially dangerous C deemed thus for whatever arbitrary reason

And

  // "safe" Rust
  ...
  // "unsafe" Rust

Life experience since I touched C for the first time in 1992.

So yes I do belive, given the quality of the code bases I have seen in production.

And as discussed at Linux Kernel Security Summit 2018, which videos are freely available for you to watch as well, even with the rigorous process to accept patchs into the kernel, CVEs keep increasing.

68% of them were caused by memory corruption, something mostly unique to C and languages that are copy-paste compatible with it.

Then another good chunk was related to UB, something that even Linus already ranted a few times.

So yeah, Safe C is an oxymoron, unless we are talking about a new variant with safety turned on by default, where warnings are dealt as errors and everyone uses static analysers that break their CI builds on error.

Static analysis.