3 ms·

> A lot of these implementations have clear merit in the sense that they are faster, safer to use, easier to scale, maintain, etc. Depends on who you ask. Hipp

> A lot of these implementations have clear merit in the sense that they are faster, safer to use, easier to scale, maintain, etc. Depends on who you ask. Hipp on Rust in 2016: Rewriting SQLite in Rust, or some other trendy “safe” language, would not help. In fact it might hurt. https://blog.regehr.org/archives/1292#comment-18452 https://blog.regehr.org/archives/1292#comment-18452 > drivers written in Rust If you have to write inline assembly, and generally bypass Rust's security features and use "unsafe" code, why wouldn't you just use C?

pjmlp 8y ago
Because it is a big difference to have 100% of the code unsafe or just a set of visible code regions marked as such.
- paavoova 8y ago
  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
  - steveklabnik 8y ago
    Static analysis.
  - pjmlp 8y ago
    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.
renox 8y ago
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.
pygy_ 8y ago
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.

pjmlp 8y ago

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

paavoova 8y ago
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
- steveklabnik 8y ago
  Static analysis.
- pjmlp 8y ago
  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.

renox 8y ago

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.

pygy_ 8y ago

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.