6 ms·

I’d imagine this will go a bit like the rust rewrite of sudo etc. Despite the memory safety advantages at least towards the start it still ends up more fragile

by Havoc 9mo ago

I’d imagine this will go a bit like the rust rewrite of sudo etc. Despite the memory safety advantages at least towards the start it still ends up more fragile because the incumbent has years of testing and fixing behind it

fulafel 9mo ago
They're not aiming at replacing SQLite-in-C with SQLite-in-Rust, they're doing this so they can implement more additional functionality faster than with C's chainsaw-juggling-act semantics and the inability to access the proprietary SQLite test suite. See the features and roadmap at https://github.com/tursodatabase/turso https://github.com/tursodatabase/turso
- thisislife2 9mo ago
  In other words, they are creating their own database and hitching on to the SQLite brand to market it. (That's fine though).
  - dlisboa 9mo ago
    I think it's fair to say they tried using SQLite but apparently had to bail out. Their use case is a distributed DBaaS with local-first semantics, they started out with SQLite and only now seem to be pivoting to "SQLite-compatible". Building off of that into a SQLite-compatible DB doesn't seem to me as trying to piggyback on the brand. They have no other option as their product was SQLite to begin with.
  - IshKebab 9mo ago
    No that's completely incorrect. It's compatible with SQLite, not just in the same spirit: > SQLite compatibility for SQL dialect, file formats, and the C API
    - yencabulator 9mo ago
      It stopped being compatible with SQLite even before the Rust rewrite: https://news.ycombinator.com/item?id=42386894 https://news.ycombinator.com/item?id=42386894
      - IshKebab 9mo ago
        That doesn't seem very fair. It's still beta and clearly far from finished. And they do call out the compromises - they have a whole page about how they are not yet fully compatible: https://github.com/tursodatabase/turso/blob/main/COMPAT.md https://github.com/tursodatabase/turso/blob/main/COMPAT.md
  - shimman 9mo ago
    I don't think that's fine at all, it's quite a shitty thing to do hoenstly and I'm not surprised it's a VC backed company doing it.
    - fragmede 9mo ago
      How would you do it then?
      - shimman 9mo ago
        I'd probably wouldn't ride the coattails of another open source project that provides hundreds of billions in value for free annually for anyone on this Earth in order to make a quick buck. IDK I have morals and it seems if you want VC funding you must lack them. It's no different than the hucksters that take public domain books and slut them up in order to make some coin peddling smut.
- adamzwasserman 9mo ago
  IMHO breaking free of SQLite's proprietary test suite is a bigger driver than C vs Rust. Turso's Limbo announcement says exactly that: they couldn't confidently make large architectural changes without access to the tests. The rewrite lets them build Deterministic Simulation Testing from scratch, which they argue can exceed SQLite's reliability by simulating unlikely scenarios and reproducing failures deterministically.
  - CharlesW 9mo ago
    > IMHO breaking free of SQLite's proprietary test suite is a bigger driver than C vs Rust. I don't understand this claim, given the breadth and depth of SQLite's public domain TCL Tests. Can someone explain to me how this isn't pure FUD? "There are 51445 distinct test cases, but many of the test cases are parameterized and run multiple times (with different parameters) so that on a full test run millions of separate tests are performed." - https://sqlite.org/testing.html https://sqlite.org/testing.html
    - einsteinx2 9mo ago
      The irony is if they only had the public domain tests, no one would complain even though it would mean the exact same number of open source tests.
      - dullcrisp 9mo ago
        That’s like if I gave you half the dictionary and then said it’s ironic that if there really weren’t any letters after “M” you wouldn’t be complaining.
    - digitalPhonix 9mo ago
      The next bullet point: > 2. The TH3 test harness is a set of proprietary tests…
      - CharlesW 9mo ago
        Of course, but how does that make the allegation not FUD?
- groundzeros2015 9mo ago
  Without the test suite isn’t even more likely to have stability problems?
  - 0x457 9mo ago
    Turso has its own test suite that in the repo.
    - groundzeros2015 9mo ago
      but the other one has decades of engineering effort and is based on real world problems
      - 0x457 9mo ago
        But the other one is not available to most and SQLite itself is "open-source" not "open-contributions" so extending SQLite is pretty much impossible at scale: - no way to merge upstream - no way to run full test-suit to be sure everything is tiptop
        groundzeros2015 9mo ago
        Indeed. That is a problem for developing SQLite without having an agreement with the developers. That is not a problem for me choosing to use SQLite in my stack.
  - dlisboa 9mo ago
    Maybe. It's hard to know what kind of issues that test suite covers. If memory safety is the main source of instability for the C implementation then the Rust implementation won't be too affected without the test suite. Same if it focus a lot on compatibility with niche embedded platforms and different OSes, which Turso won't care to lose. "Stability" is a word that means different things for different use cases.
    - groundzeros2015 9mo ago
tracker1 9mo ago
I definitely wouldn't be surprised by bugs and/or compatibility issues over time. Especially in the near term. I'm mixed, but somewhat enthusiastic on Turso's efforts to create client-server options and replication. In the past I've reached for FirebirdSQL when I needed local + external databases and wanted to limit the technology spread... In the use case, as long as transactions synched up even once a week it was enough for the disparate remote connections/systems. I'm honestly surprised it isn't used more. That said, SQLite is more universal and lighter overall.
- adamzwasserman 9mo ago
  Building a production app on Turso now. No bugs or compatibility issues so far. The sqlite API isn't fully implemented yet, so I wrote a declarative facade that backfills the missing implementations and parallels writes to both Turso and native sqlite: gives me integrity checking and fallback while the implementation matures
zbentley 9mo ago
Isn’t the rust rewrite deployed as part of some fairly significant Linux distros these days? That’s hearsay that I haven’t dug into, so I may well be wrong.
- ktimespi 9mo ago
  Ubuntu is deploying it in a non-LTS release, and they're trying to get the bugs out of the way is what I'm hearing
SpecialistK 9mo ago
Of all the projects which may benefit from a rewrite or re-imagining in a memory-safe language, I'm really puzzled why it's heavily-tested, near-universally-deployed software such as sudo (use oBSD doas instead?), the coreutils, and sqlite.
- Havoc 9mo ago
  I don't think there is a big picture plan. It requires that someone care both about rust and the thing ...which is a pretty arbitrary combination
- dizhn 9mo ago
  Doas supports a subset of sudo functionality by design. Your comment is exactly what I said when I first heard about the rust linux utils thing. The best they can do is have new bugs.

by Havoc 9mo ago

fulafel 9mo ago

They're not aiming at replacing SQLite-in-C with SQLite-in-Rust, they're doing this so they can implement more additional functionality faster than with C's chainsaw-juggling-act semantics and the inability to access the proprietary SQLite test suite. See the features and roadmap at https://github.com/tursodatabase/turso https://github.com/tursodatabase/turso

thisislife2 9mo ago
In other words, they are creating their own database and hitching on to the SQLite brand to market it. (That's fine though).
- dlisboa 9mo ago
  I think it's fair to say they tried using SQLite but apparently had to bail out. Their use case is a distributed DBaaS with local-first semantics, they started out with SQLite and only now seem to be pivoting to "SQLite-compatible". Building off of that into a SQLite-compatible DB doesn't seem to me as trying to piggyback on the brand. They have no other option as their product was SQLite to begin with.
- IshKebab 9mo ago
  No that's completely incorrect. It's compatible with SQLite, not just in the same spirit: > SQLite compatibility for SQL dialect, file formats, and the C API
  - yencabulator 9mo ago
    It stopped being compatible with SQLite even before the Rust rewrite: https://news.ycombinator.com/item?id=42386894 https://news.ycombinator.com/item?id=42386894
    - IshKebab 9mo ago
      That doesn't seem very fair. It's still beta and clearly far from finished. And they do call out the compromises - they have a whole page about how they are not yet fully compatible: https://github.com/tursodatabase/turso/blob/main/COMPAT.md https://github.com/tursodatabase/turso/blob/main/COMPAT.md
- shimman 9mo ago
  I don't think that's fine at all, it's quite a shitty thing to do hoenstly and I'm not surprised it's a VC backed company doing it.
  - fragmede 9mo ago
    How would you do it then?
    - shimman 9mo ago
      I'd probably wouldn't ride the coattails of another open source project that provides hundreds of billions in value for free annually for anyone on this Earth in order to make a quick buck. IDK I have morals and it seems if you want VC funding you must lack them. It's no different than the hucksters that take public domain books and slut them up in order to make some coin peddling smut.
adamzwasserman 9mo ago
IMHO breaking free of SQLite's proprietary test suite is a bigger driver than C vs Rust. Turso's Limbo announcement says exactly that: they couldn't confidently make large architectural changes without access to the tests. The rewrite lets them build Deterministic Simulation Testing from scratch, which they argue can exceed SQLite's reliability by simulating unlikely scenarios and reproducing failures deterministically.
- CharlesW 9mo ago
  > IMHO breaking free of SQLite's proprietary test suite is a bigger driver than C vs Rust. I don't understand this claim, given the breadth and depth of SQLite's public domain TCL Tests. Can someone explain to me how this isn't pure FUD? "There are 51445 distinct test cases, but many of the test cases are parameterized and run multiple times (with different parameters) so that on a full test run millions of separate tests are performed." - https://sqlite.org/testing.html https://sqlite.org/testing.html
  - einsteinx2 9mo ago
    The irony is if they only had the public domain tests, no one would complain even though it would mean the exact same number of open source tests.
    - dullcrisp 9mo ago
      That’s like if I gave you half the dictionary and then said it’s ironic that if there really weren’t any letters after “M” you wouldn’t be complaining.
  - digitalPhonix 9mo ago
    The next bullet point: > 2. The TH3 test harness is a set of proprietary tests…
    - CharlesW 9mo ago
      Of course, but how does that make the allegation not FUD?
groundzeros2015 9mo ago
Without the test suite isn’t even more likely to have stability problems?
- 0x457 9mo ago
  Turso has its own test suite that in the repo.
  - groundzeros2015 9mo ago
    but the other one has decades of engineering effort and is based on real world problems
    - 0x457 9mo ago
      But the other one is not available to most and SQLite itself is "open-source" not "open-contributions" so extending SQLite is pretty much impossible at scale: - no way to merge upstream - no way to run full test-suit to be sure everything is tiptop
      - groundzeros2015 9mo ago
        Indeed. That is a problem for developing SQLite without having an agreement with the developers. That is not a problem for me choosing to use SQLite in my stack.
- dlisboa 9mo ago
  Maybe. It's hard to know what kind of issues that test suite covers. If memory safety is the main source of instability for the C implementation then the Rust implementation won't be too affected without the test suite. Same if it focus a lot on compatibility with niche embedded platforms and different OSes, which Turso won't care to lose. "Stability" is a word that means different things for different use cases.
  - groundzeros2015 9mo ago

tracker1 9mo ago

I definitely wouldn't be surprised by bugs and/or compatibility issues over time. Especially in the near term. I'm mixed, but somewhat enthusiastic on Turso's efforts to create client-server options and replication. In the past I've reached for FirebirdSQL when I needed local + external databases and wanted to limit the technology spread... In the use case, as long as transactions synched up even once a week it was enough for the disparate remote connections/systems. I'm honestly surprised it isn't used more. That said, SQLite is more universal and lighter overall.

adamzwasserman 9mo ago
Building a production app on Turso now. No bugs or compatibility issues so far. The sqlite API isn't fully implemented yet, so I wrote a declarative facade that backfills the missing implementations and parallels writes to both Turso and native sqlite: gives me integrity checking and fallback while the implementation matures

zbentley 9mo ago

Isn’t the rust rewrite deployed as part of some fairly significant Linux distros these days? That’s hearsay that I haven’t dug into, so I may well be wrong.

ktimespi 9mo ago
Ubuntu is deploying it in a non-LTS release, and they're trying to get the bugs out of the way is what I'm hearing

SpecialistK 9mo ago

Of all the projects which may benefit from a rewrite or re-imagining in a memory-safe language, I'm really puzzled why it's heavily-tested, near-universally-deployed software such as sudo (use oBSD doas instead?), the coreutils, and sqlite.

Havoc 9mo ago
I don't think there is a big picture plan. It requires that someone care both about rust and the thing ...which is a pretty arbitrary combination
dizhn 9mo ago
Doas supports a subset of sudo functionality by design. Your comment is exactly what I said when I first heard about the rust linux utils thing. The best they can do is have new bugs.