6 ms·

"What I would love to see is a $PROJ rewrite in Rust." has kinda become a mantra of mine, particularly for things like SQLite which are core dependencies of so

"What I would love to see is a $PROJ rewrite in Rust." has kinda become a mantra of mine, particularly for things like SQLite which are core dependencies of so many other things.

coldtea 11y ago
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).
- pcwalton 11y ago
  How is the Rust toolchain lacking? "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.
  - Sanddancer 11y ago
    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.
    - pcwalton 11y ago
      "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.
      - willhinsa 11y ago
        If that 1% of people are the ones paying money for it, why shouldn't the developers focus on their needs?
        willhinsa 11y ago
        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.
        icebraining 11y ago
        Disagreeing isn't a reason to downvote. Why not? There's no rule on HN against it, and the founder of HN thinks it's ok, since upvotes are used to indicate agreement.
        DanBC 11y ago
        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. PG has said gently conflicting things: Downvoting to disagree is a problem that needs action: https://news.ycombinator.com/item?id=1057347 https://news.ycombinator.com/item?id=1057347 Downvoting to disagree is fine if people are also upvoting to agree: http://news.ycombinator.com/item?id=117171 http://news.ycombinator.com/item?id=117171 Worry about excessive downvotes is a long term problem on HN. Here's a post from seven years ago: https://news.ycombinator.com/item?id=214398 https://news.ycombinator.com/item?id=214398
        pcwalton 11y ago
        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.
      - coldtea 11y ago
        >"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. Now if it was a Rust-based Sendmail...
  - coldtea 11y ago
    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?
    - pcwalton 11y ago
      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!
      - coldtea 11y ago
        >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.
WaxProlix 11y ago
The problem is that it isn't so much about an interface-compatible version of $project in Rust - the value of things like SQLite is in the huge amount of testing and perf work that's been done over the years. You could do a toy reimplementation, but the value wouldn't be there.
- TranquilMarmot 11y ago
  Sure the value would be there! After a huge amount of testing and perf work done over the course of 15 years...
- pygy_ 11y ago
  Mozilla has a license for the full test suite (which AFAIK uses the public interface), and Rust interoperates nicely with C... The perf works would remain to be done, though, after the whole thing is made to work.
  - vvanders 11y ago
    That's the exact line I was thinking of, It'd be curious to see how reimplementing an existing C-api library looks in Rust. One of the huge benefits is the lifetime analysis which you lose soon as you cross the FFI boundary.
    - pygy_ 11y ago
      AFAIK the SQLite API is rather tight. You mostly pass in and get back strings (SQL and rows of tuples, respectively).
- rcthompson 11y ago
  Luckily a huge amount of that testing work has been captured in a comprehensive test suite for SQLite that any alternative implementation could easily use to ensure compatibility.
  - monocasa 11y ago

"What I would love to see is a $PROJ rewrite in Rust." has kinda become a mantra of mine, particularly for things like SQLite which are core dependencies of so many other things.

coldtea 11y ago

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

pcwalton 11y ago
How is the Rust toolchain lacking? "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.
- Sanddancer 11y ago
  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.
  - pcwalton 11y ago
    "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.
    - willhinsa 11y ago
      If that 1% of people are the ones paying money for it, why shouldn't the developers focus on their needs?
      - willhinsa 11y ago
        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.
        icebraining 11y ago
        Disagreeing isn't a reason to downvote. Why not? There's no rule on HN against it, and the founder of HN thinks it's ok, since upvotes are used to indicate agreement.
        DanBC 11y ago
        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. PG has said gently conflicting things: Downvoting to disagree is a problem that needs action: https://news.ycombinator.com/item?id=1057347 https://news.ycombinator.com/item?id=1057347 Downvoting to disagree is fine if people are also upvoting to agree: http://news.ycombinator.com/item?id=117171 http://news.ycombinator.com/item?id=117171 Worry about excessive downvotes is a long term problem on HN. Here's a post from seven years ago: https://news.ycombinator.com/item?id=214398 https://news.ycombinator.com/item?id=214398
      - pcwalton 11y ago
        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.
    - coldtea 11y ago
      >"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. Now if it was a Rust-based Sendmail...
- coldtea 11y ago
  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?
  - pcwalton 11y ago
    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!
    - coldtea 11y ago
      >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.

WaxProlix 11y ago

The problem is that it isn't so much about an interface-compatible version of $project in Rust - the value of things like SQLite is in the huge amount of testing and perf work that's been done over the years. You could do a toy reimplementation, but the value wouldn't be there.

TranquilMarmot 11y ago
Sure the value would be there! After a huge amount of testing and perf work done over the course of 15 years...
pygy_ 11y ago
Mozilla has a license for the full test suite (which AFAIK uses the public interface), and Rust interoperates nicely with C... The perf works would remain to be done, though, after the whole thing is made to work.
- vvanders 11y ago
  That's the exact line I was thinking of, It'd be curious to see how reimplementing an existing C-api library looks in Rust. One of the huge benefits is the lifetime analysis which you lose soon as you cross the FFI boundary.
  - pygy_ 11y ago
    AFAIK the SQLite API is rather tight. You mostly pass in and get back strings (SQL and rows of tuples, respectively).
rcthompson 11y ago
Luckily a huge amount of that testing work has been captured in a comprehensive test suite for SQLite that any alternative implementation could easily use to ensure compatibility.
- monocasa 11y ago