SQLite is rather heavily used in the embedded world, which uses a lot of architectures that llvm hasn't been ported to. Hitachi's SH, NEC's v850, etc are all targets people pay the sqlite maintainers for test suites, porting, etc. A rewrite in rust would eliminate a lot of income the developers of sqlite count on, because the toolchain just doesn't have the breadth of targets that c does.
"Nobody should bother developing an alternative to SQLite because 1% of SQLite's users won't be able to run it" isn't a valid argument against developing an alternative any more than "Microsoft shouldn't bother developing Windows 95 because some users still have a 286" would have been in 1993.
Nobody is saying that those who need SQLite as it exists today shouldn't continue to fund its development. It's just that writing off the development of alternatives as unrealistic because they'll only be runnable by 99% of SQLite's install base as opposed to 100% of it is silly.
Kind of ridiculous that someone downvoted this. Aren't downvotes supposed to suggest that the comment detracted from the conversation? In what way am I detracting from the discussion? Disagreeing isn't a reason to downvote.
Ignore individual downvotes. They're often mistakes, or people in bad moods, or etc. They usually get corrected, although as you've seen not enough people provide corrective upvotes.
Downvote for disagreement has a bit of history on HN.
I'm not implying anything about what SQLite's development priorities should be. I'm arguing against the idea that developing a SQLite alternative in Rust is infeasible for portability reasons.
>"Nobody should bother developing an alternative to SQLite because 1% of SQLite's users won't be able to run it"
...and a 80% or more of the rest 99% wont bother to run it, because all it buys them is hassle, as SQLite is present everywhere, well maintained by the guy who wrote it, with lots of books on it, interfaces for all their favorites languages and environments, tested thoroughly by its dev, and battle proven.
Of course somebody can write it in Rust, and do whatever they like. It might even catch on eventually.
But merely "it will be more secure because of advanced compiler technology" is not that enticing an argument -- especially if people don't have many security issues with it in the first place.
At this point you're arguing against a lot of things I've never said. Obviously an alternative to SQLite will have to be compelling enough to motivate its use in ways that likely exceed just memory safety concerns. That is true of any proposed replacement for any piece of software. The point is simply that, if you want to write a SQLite alternative, Rust is a reasonable language to write it in.
>At this point you're arguing against a lot of things I've never said.
Yeah, didn't say you said those.
But since I started this subthread, I'm merely expanding and explaining further the thigs I said initially.
>The point is simply that, if you want to write a SQLite alternative, Rust is a reasonable language to write it in.
Oh, on that I agree.
I was mainly questioning the need to rewrite in the first place (and especially for this particular software, being an embedded db et al), not whether Rust as a language is a good choice to do so.
That said, the less mature ecosystem/toolchain etc, is still an issue for some projects that would still benefit from Rust -- e.g. for somebody used to work with VS C++, etc.
