In defense of defensiveness

In defense of defensiveness gently reminds us that even with all our efforts to create psychological safety within teams, work environments are still stalked with other fears which we have little control over at the team level:

Our workplaces are, for the most part, not teeming with the undead. But they are also not entirely safe, either. We can, given enough attention and care, create some relative safety together—and I know a great many people out there doing everything they can to that end. But the reality is that we are always subject to potential harm, whether from each other (through malice or ignorance or both), or whether from those who pull the strings of stock prices and venture capital and hype cycles, heedless of the bodies they leave strewn behind. There is no perfect safety for the living, I’m afraid.

And, on top of that, it also gave me a suggestion for my to-read list, The Steerswoman.

Nice 👌.

I ported my toy database index to Rust and I liked it

I like Go a lot, and have been writing production Go for about seven years now. It runs some critical bits of Cloudant.

But I thoroughly enjoyed rewriting my Go toy document database into a Rust toy document database. So I can say now that I also like Rust a lot.

(My view on Go, Rust, Zig, Swift and other recent compiled-but-nice languages is that we have an embarrassment of riches available to us these last few years compared to what went before. For so long systems programming was “C/C++ or go home”. In my Rust book there’s a quote, “Rust: systems programmers can have nice things too”. I think that’s correct.)

(But back to what we were talking about.)

At this point, I have just finished getting the Rust code to feature equivalence with the Go code. It’s slightly better, even: the Rust code can handle arrays, which I never got to for the Go code. The Rust codebase is 1,076 lines of code while the Go codebase is 1,210 lines of code — pretty comparable. While a thousand lines of code isn’t very much, I feel that I’ve learned a lot of Rust along the way. I’d feel comfortable writing Rust in a production environment, albeit hopefully with some other people who were able to correct my still-a-novice screw-ups.

There were several places I found Rust outshone Go for this project. So instead of talking about what I’ve learned — which would be confusing for people who don’t know Rust and boring for those who do know it — I’ll talk about the parts of Rust that made this rewrite so enjoyable.

Those were:

  • Strictness
  • Representing JSON
  • Result and Option
  • Expressions all return things

It’s all a bit honeymoon period, I think; Rust and me right now. I’m sure there are frustrating things with Rust, but this project hasn’t exposed them (yet). So be generous. Spare me a moment to enjoy the honeymoon 🌇, and let’s suspend our inner cynics and talk about these things I liked.

Read More…

Found languages: Inko and Gleam

Today, some quick notes on two relatively young languages I came across recently that I found interesting. Both combine things I like in Rust (an advanced type system) and Erlang (nice concurrency primitives).

Read More…

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…