How is Rust in regards to the SQLite's requirements now?
Didn't make any sense at any point post 1.0. Rust 1.0 code still works today modulo BC breaks required to fix unsoundnesses.
> Rust needs to demonstrate that it can be used to create general-purpose libraries that are callable from all other programming languages.
Also didn't make much sense at any point as the story there was always straightforward. But efforts like librsvg have pretty much demonstrated that (interestingly the libsrvg conversion effort started around the time that page was created, circa 2017).
> Rust needs to demonstrate that it can produce object code that works on obscure embedded devices, including devices that lack an operating system.
Rust is used in a bunch of embedded contexts. Whether Rust can produce object code that works on your embedded device is a more debatable question, depends on the existence (and quality) of the proper llvm backend.
I think there's also a gcc frontend in the works, but I expect it's essentially nowhere yet as it was only just started (few months old I think?). Though I believe it has financial support and a fair amount of manpower. I believe there's also an even more recent effort for a gcc backend in rustc.
So yeah this one I'd say there's limited progress yet but things seem to be moving in the right direction and picking up.
> Rust needs to pick up the necessary tooling that enables one to do 100% branch coverage testing of the compiled binaries.
Unclear what the issue is there so no idea.
> Rust needs a mechanism to recover gracefully from OOM errors.
That was always possible by working no_std, though of course required reimplementing your own abstractions.
With the linux kernel integration effort, a lot more work is going into "fallible allocation" APIs, and thus the ability to gracefully recover from allocation failures.
> Rust needs to demonstrate that it can do the kinds of work that C does in SQLite without a significant speed penalty.
¯\_(ツ)_/¯
Yes that's because it's a requirement designed by a standards body. I found a paper "Is 100% Test Coverage a Reasonable Requirement? Lessons Learned from a Space Software Project" (2017) that mentions that 100% branch coverage is a requirement in European Cooperation for Space Standardization (ECSS) for Class A software (where failure could result in loss of life, etc). The paper concluded:
> Our findings include that there seems to be a break-even point between 80% and 95%, and everything beyond this points is increasingly costly and could introduce new project risks—which confirms findings reported so far in literature (Section 5). However, the interview revealed that, still, 100% coverage can be a reasonable quality requirement; even though a 100% requirement is not a good indicator for the software quality as such.
https://www.researchgate.net/publication/319141355_Is_100_Te...
It doesn't follow that because rust is a safe language that it cannot expose test harnesses that would enable 100% branch coverage. Personally I'm ambivalent on this, maybe it's not useful, but it doesn't seem bad either. But your reaction to this requirement seems weird, like the "fox and the grapes" fable... You can't get 100%-branch coverage, so you give up and claim that 100% branch coverage is dumb, why would anyone want that anyway? Do you really think that 100% branch coverage testing should be unavailable to rust programmers if that's what they need (for whatever reason, including meeting some admittedly arbitrary standard)?
I seem to recall an interview where the SQLite creator, Richard Hipp, described the reasons behind the branch coverage testing in a bit more detail and mentioned that it was a requirement from one of their customers, which is where I got that idea. Sorry I don't have a specific reference.
LLVM's support is really quite lacking that this issue alone is enough of a justification for a project like SQLite to be written in C. The rust-gcc effort you mentioned will hopefully solve this.
Quite a few of the others really are they just don't want to be pioneers which is really quite fair.
The Allocator API is about the ability to mix allocators and provide "precise" (per-object) allocation strategies. That's orthogonal to fallible allocation, which is mostly about adding fallible versions of possibly-allocating APIs, and being able to statically remove access to the non-failing one (and being able to implicitly reject any dependency relying on those APIs) (and / or providing alternate implementations which expose a fallible API which is what fallible_collections does, but the stdlib seems to have gone with adding fallible APIs and probably adding a compiler feature / flag to be able to disable the non-failig ones)
(Or is SQLite portable to architectures that GCC does not support?)
Do those exist?
(Yeah, there are some microcontrllers that can only be programmed by the manufacturer's C compiler, that doesn't even support the entire language and is full of bugs. But I would be very surprised if SQLite run on a PIC.)
IIRC a possible issue is the use of forks of gcc (or something else), I think it used to be common for console toolchains though maybe less so these days.