1. 14
  1. 7

    RIIR apparently stands for Rewrite It In Rust

    1. 5

      The maintainers of sqlite actually consider Rust as a reimplementation language (Link), but currently Rust just wont do.

      Some preconditions that must occur before SQLite is recoded in Rust include:

      • Rust needs to mature a little more, stop changing so fast, and move further toward being old and boring.
      • Rust needs to demonstrate that it can be used to create general-purpose libraries that are callable from all other programming languages.
      • Rust needs to demonstrate that it can produce object code that works on obscure embedded devices, including devices that lack an operating system. Rust needs to pick up the necessary tooling that enables one to do 100% branch coverage testing of the compiled binaries.
      • Rust needs a mechanism to recover gracefully from OOM errors. Rust needs to demonstrate that it can do the kinds of work that C does in SQLite without a significant speed penalty.

      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.

      To me this looks like a clear roadmap of what needs to happen for RIIR.

      1. 1

        I’m a fan of Rust, but I also think that list isn’t even complete. The sqlite code is a big battle tested thing with hard downwards requirements (even for the binary format) and various embedded requirements. So RiiR is a showstopper and will probably do more harm to Rust than anything else. Which is why I don’t actually like this submission at all.

      2. 4

        “Rewritten” is a stretch here. It’s more like C sqlite still being in C, but compiled with rustc.

        I would like a fresh take on sqlite with more focus on concurrent performance, but refracting C codebase to be it is likely more work than starting from scratch.

        1. 10

          SQLite already has good read concurrency (readers are never blocked) if you use WAL mode; but supporting multiple simultaneous writers would add a lot of architectural complexity and turn it into a different thing altogether.

          1. 1

            https://www.actordb.com/ is a fun exploration here.

            1. 2

              Interesting … a distributed db server based on SQLIte.

              SQLite is just a software library. Not a database server. It has no replication. This is where our “well how hard could it be?” comes out.

              There are multiple ways you can implement replication to a database. You can replicate SQL statements and apply them on every server. This is the simpler solution and one we went with first. It worked reasonably well but was not optimal by any means.

              Right now what we do is replicate the actual WAL log. One node executes, the others just append to WAL. This way no random() can cause inconsistency.

          2. 4

            It’s a joke (hence the tag “satire”) but I agree with your wish. Unfortunately it’s a ton of effort and the right people must get together to make it happen.