Rust: using String and &str in your APIs

As part of writing my toy document database, I have to deal with a lot of strings. As part of my Rust rewrite, I have found that Rust is more complicated than Go in this regard.

Rust has two main string types (and a few more for good measure, but they don’t come up so often). Coming from Go, this was something that kept bugging me. I didn’t have a good handle on which to use. In Go, you pretty much always pass around Go’s standard string type, which is a slice of runes (a Go rune is a UTF-8 character point).

Rust, however, has two string types — String and &str — that one has to repeatedly choose between. Or so it felt like to me. Though it is my first non-trivial rust project, I wanted at least somewhat idiomatic APIs for my toy document database. So I went looking for guidance. Were there rules of thumb that I could rely on, or was seemingly every function definition going to need deep thought to choose one or the other?

Frankly, it’s clear I’m not the first person to ask this question! And, fortunately, there do appear to be straightforward patterns that cover most situations. This post pulls together a summary of the guidelines I found. I link to my sources, which give a much more complete coverage of the subject and are therefore very worthy of your attention too 🙂.

Read More…

Archiving data in glass

Most digital storage mediums age worse than paper, and certainly worse than words carved into stone. Tapes last a decade or two. Hard disks and SSDs less time still — you need to replace them about every five years if you want to be confident in not losing something along the way. So how do we keep digital data for a long time — hundreds or thousands of years?

Microsoft’s Project Silica is one attempt to answer this question.

Read More…

Journal: Rust DocDB; VS Code Helix keymap

A couple of notes for my future self, to remember some things, and when I started some other things.

  • First, a decision to use Rust for my Build Your Own Database Project, or, at least, a hankering to take an opportunity to learn more Rust.
  • Second, a short journey of discovery into whether I’d be able to keep using a Helix-like workflow in VS Code, if I ever had to go back to that editor.

Read More…

Link: The Unforeseen Costs of Extraordinary Experience

I came across this paper a while ago, and the conclusions stuck with me. That having some kind of fancy experience, which you might expect to make you the centre of attention in social situations, actually can end up feeling alienating. Because it marks you as different.

It also reminded me of something I’d often noticed. When I meet with old friends we often dwell on quite normal things, but ones where we shared them. “Do you remember this thing we did together?”, “Yes, I remember doing that thing with you, wasn’t it funny when …?”. And the paper’s conclusions kind of make sense of this: we enjoy feeling part of a group, and reaffirming we remember this or that experience we had together is a good way to do that.

It probably doesn’t have to be a normal thing, strictly I suppose it could be, “Do you remember the time we both went up in a rocket ship and saw the Earth from space?”, “Yes, I remember going up in a rocket ship with you, and wasn’t it funny when you splurted space food out your nose!” But for most people it’s more likely to be something more mundane 😂

People seek extraordinary experiences—from drinking rare wines and taking exotic vacations to jumping from airplanes and shaking hands with celebrities. But are such experiences worth having? We found that participants thoroughly enjoyed having experiences that were superior to those had by their peers, but that having had such experiences spoiled their subsequent social interactions and ultimately left them feeling worse than they would have felt if they had had an ordinary experience instead.

From The Unforeseen Costs of Extraordinary Experience — hit “Read full-text” rather than “Download full-text PDF” to read online for free.

Build your own Database Index: part 4

In this forth part of a series about writing a simple JSON document index, we’ll talk about the ways that we can update and delete documents from the index.

Most — all? — tutorials I could find online about making simple indexes only covered adding documents to the index and basic querying. It turns out that updating the index is quite an interesting problem, with various different approaches depending on the data format used to represent the index, and the strategy we use to update our indexes. So I think it’s useful to expand our series to talk more about this.

As this is a spare-time learning exercise for me, we’ll end up with a pretty simple system. It’s not super-impractical for real world use, however, albeit with a bit more thought put into efficiency. And error handling, of course 🙃. But even this simple system shows a few tradeoffs we have to make in real world systems, in particular using more disk space to make updates faster.

Time to dig in.

Read More…