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

Regarding SQLite, here's the official tune (https://www.sqlite.org/whyc.html#why_isn_t_sqlite_coded_in_a_safe_language_ 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.