1. 25

  2. 2

    This article doesn’t speak about cache invalidation at all - and isn’t that the hard part?

    1. 2

      Cache invalidation is hard in any language; the things that make it hard aren’t Rust-specific. This article is about how the design of Rust makes writing caches more difficult than one may expect.

    2. 1

      The same thing comes up in C++ too. It has a “mutable” keyword for marking a class member as eligible to be mutated by a const method.

      1. 1

        Data-oriented thinking would compel us to get rid of deserialization step instead, but we will not pursue that idea this time.

        I found this statement interesting, but I’m finding it pretty difficult to imagine what this would look like. Could someone with more knowledge of data-oriented thinking explain this?

        1. 3

          So if we think about this, the db interface itself, where it returns a freshly-allocated Vec of bytes, is redundant. It necessary includes a copy somewhere, to move the data from bytes on-disk to Rust managed heap.

          It probably is possible to get at those bytes in a more direct way: most likely db either mmaps the file, or includes some internal caches. Either way, you probably can get a zero-copy &[u8] out of it. And it should be possible to “cast” that slice of bytes to &Widget, using something like arkyv or abonotation. That is, if Widget struct is defined in such way that bytes-in-the-form-they-are-on-disk are immediately usable.

          1. 2

            Or something like https://capnproto.org/

        2. 1

          I really like this article, because it’s a marked departure from the usual approach to Rust tutorials of showing you several version of the program, none of which compile, then basically telling you how to solve each compiler error. Instead, it focuses on building a model that leverages Rust’s data access model to safely implement things that are tough to get right.

          It’s a little unfortunate that the mechanism of the solutions isn’t explored in more depth. Interior mutability is nicely introduced as a good approach to solving the problem of initialisation but then it’s used via the once_cell crate.

          That’s obviously understandable given what the article is based on and, furthermore, I think it’s actually the right approach “in production”. This isn’t intended as criticism of the post, but as an encouragement for the readers who liked it to dig a little into once_cell and elsa because both make for very instructive readings of idiomatic Rust.

          1. 1

            Yeah, “how once_cell works?” would make for a good post one day… There’s a surprising amount of details to get wrong there!