Writing a small library in Rust, part 0

As I was parting ways with Facebook I realized I should find something other than endless leetcode exercises to keep my head in the game. Despite having done a number of coding screens over the years I still get performance anxiety and I am still actively chipping away at my self-perception as an impostor programmer, and of course having something on my Github that was potentially useful and demonstrated I know how things like test coverage and CI work might possibly be career enhancing.

Towards that end I returned to one of the things I have thought was genuinely cool that I came across in the last 6 months the k-sortable unique ID. Segment.io blogged about UUIDs and its a really good read about the different existing types and the tradeoffs they involve. The end result of their research and innovation is the Ksuid which they implemented in Go.

While Go is cool and I have been doing little odds and ends in it I decided I instead wanted to work in Rust. I found an existing implementation but I wanted an implementation with some small differences and a slightly different public interface as well. That is to say I rationalized for a few moments and came up with acceptable pseudo-reasons to do the totally reasonable thing of writing my own pet project and making it available open source. 😉

As a result I wrote and published a new crate rksuid which should be compatible with Segment ksuids (assuming my tests are correct and comprehensive enough.)

This was a first for me and I am pretty pleased with the fact I was able to ship a usable version in about two days of part time development and then iterate on it and the CI setup over a few more days to get a big perf boost and setup proper CI with code coverage and working badges on the crate for both.

Looking at lib.rs in the initial commit it is already largely in the shape it has remained in, this isn’t exactly a complex problem so there isn’t a lot of need for intense upfront design.

Turning to actual code the definition of a Ksuid struct is quite simple:

pub struct Ksuid {
        pub timestamp: u32,
        pub payload: u128,
    }

This is the first major difference from the existing ksuid crate which stores the ksuid as an array of bytes and requires calling methods to get the raw timestamp or payload. I decided to opt for public fields with the underlying types and bank on going to and from byte slices will be cheap/fast enough and then provide a lot of similar convenience methods for ergonomic access.

There isn’t a lot of code in this commit, just enough functionality to begin testing the public API and surface most runtime issues that might emerge. The next post will look at the serialize method and the deserialize function and their associated testing and benchmarking.