Yeah, let's rewrite $PROJ in a language few people use, with a lacking toolchain, and that few people will be bothered to use said rewrite, since it will make their life difficult to connect to it (they'd need a Rust toolchain to compile it for one).
"Few people will use a Rust library because they'd need a Rust compiler" doesn't make sense to me, because odds are good that the Rust compiler can target the platform you used to post this comment.
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.
For one, you're still making breaking changes to it. Then there's issues like a full blown debugger, the compiler is slow, etc. Maturity. I'm not even going into IDE terittory which Windows guys will want.
SQLite is used in tons of software. Why add a Rust compiler dependency on its build stage, if SQLite already serves them well and they already work in C/C++ land for the rest of the code of their project?
Rust isn't making breaking changes anymore. I think people are getting hung up on "theoretically breaking" changes that don't break anybody in practice and are equivalent to the "theoretically breaking" changes that C and C++ (and every other actively developed language) continue to make all the time.
> SQLite is used in tons of software. Why add a Rust compiler dependency on its build stage, if SQLite already serves them well and they already work in C/C++ land for the rest of the code of their project?
Because a replacement might have more features/better performance/improved security? These are the same reasons you might look for alternatives for any piece of software!
>Rust isn't making breaking changes anymore. I think people are getting hung up on "theoretically breaking" changes that don't break anybody in practice and are equivalent to the "theoretically breaking" changes that C and C++ (and every other actively developed language) continue to make all the time.
That's good to know. In the language OK, not even in the standard lib?
>Because a replacement might have more features/better performance/improved security? These are the same reasons you might look for alternatives for any piece of software!
Most of that (more features, better performance) are orthogonal to Rust. Features obviously (if anything a port will probably have even LESS features initially, as Sqlite got most of its features piecemeal too).
And how is better speed assured with the Rust rewrite considering that Sqlite is pretty fast C already?
At best it might be the same speed (and if it's an algorithmic issue that slows down Sqlite, then of course they can also fix their C code and overcome that).
Which leaves us with "better security". Is it compelling enough to change software? Depends, I say.
