Comment by josephg

7 hours ago

I'm not sure I buy this from a technical perspective. Rust already meets almost all of the criteria laid out at the end of this post. By all means keep using C if you like it, but the rust team has done an excellent job over the last few years addressing most of these issues.

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

Rust moves at a pretty glacial pace these days. Slower than C++ for sure. There haven't been any big, significant changes to the language since async. Code that compiles today should compile indefinitely. (And the rust compiler authors check this on every release, by recompiling basically everything in crates.io to make sure.)

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

Rust matches C in this regard. You can import & export C functions from rust very easily. The consumer of the foreign function interface have no idea they're calling rust and not C.

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

Rust works pretty well on raw / embedded hardware via #[no_std]. There's a few obscure architectures supported by gcc and not llvm (and by extension rust). But it generally works great. I'd love to know what the real blocker platforms are (if any).

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

Uh, I think this is possible today? Rustrover (intellij) can certainly produce coverage reports. This doesn't feel out of reach.

> - Rust needs a mechanism to recover gracefully from OOM errors.

True. You can override the global allocator for a program and use that to detect OOM. But recovering from OOM in general is tricky. I personally wish rust's handling of allocators looked more like zig.

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

Rust and C are pretty much even when it comes to performance. Rust binaries are often a bit bigger though.

4 comments

josephg

Reply
thethirdone  6 hours ago

The criteria were laid out in 2019 [0]. It was less clear then.

> 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.

It seems like the criteria are less of things the SQLite developers are claiming Rust can't do and more that they are non-negotiable properties that need to be considered before even bringing the idea of a rust version to the team.

I think it is at least arguable that Rust does not meet the requirements. And they did explicitly invite private argument if you feel differently.

0: https://web.archive.org/web/20190423143433/https://sqlite.or...

  • josephg  6 hours ago

    Ah, I assumed the page was written recently due to this message at the bottom:

    >> This page was last updated on 2025-05-09 15:56:17Z <<

    > I think it is at least arguable that Rust does not meet the requirements

    Absolutely. The lack of clean OOM handling alone might be a dealbreaker for sqlite. And I suspect sqlite builds for some weird platforms that rustc doesn't support.

    But I find it pretty weird reading comments about how rust needs prove it performs similarly to C. Benchmarks are just a google search away folks.

    > And they did explicitly invite private argument if you feel differently.

    Never.

    Its not up to me what language sqlite is written in. Emailing the sqlite authors to tell them to rewrite their code in a different language would be incredibly rude. They can write sqlite in whatever language they want. My only real choice is whether or not I want to use their code.

oguz-ismail2  6 hours ago

> Rustrover (intellij) can certainly produce coverage reports.

See <https://sqlite.org/testing.html#statement_versus_branch_cove...>. Does Rustrover produce branch coverage reports?