selfaware soup

Esther Weidauer

Week of Borrowing


Abstract painting, background: dark blue with grey wood grain texture, foreground: green/red corrosion pattern in a vertical slice in the middle of the frame.

What do crabs eat anyway? - Internet drama, Rust, and Submarines

In order to learn more about Rust, I’ve started last years Advent of Code and I think I’m making good progress. I’m now at day 12 and the puzzles are getting a lot more tricky. Doing them in Rust reveals more of the shortcuts I used to take in programming with other languages and that engages a certain part of my brain that’s very fun. I put my solution up on Github, if you want to take a look. The theme is about exploring the ocean floor in a weird and barely functioning submarine and it’s very cute.

Each puzzle has two parts and there’s a lot of potential to build yourself into a corner during part one and then having to rewrite a lot from scratch during part two. So far that hasn’t really happened for me. The intuition for “Should I build this for some foresight?” I got from many years of professional coding seems to still be there.

I made some more realizations about Rust that help me “get it” more. Some of them seem really obvious in hindsight but I struggled with them for a while. One is about moving ownership. Somehow I had assumed that when you move a value into a new scope (e.g. by passing it into a function as an argument without creating a reference), you wouldn’t be able to get it back into the original scope. Consider this code:

fn append_one(mut sequence: Vec<u64>) {

let sequence = vec![1,2,3];
println!("{:?}", sequence);

If you try to run it, it’ll complain that sequence has moved and can’t be accessed anymore:

error[E0382]: borrow of moved value: `sequence`
  --> src/
39 |     let sequence = vec![1,2,3];
   |         -------- move occurs because `sequence` has type `Vec<u64>`, which does not implement the `Copy` trait
40 |     append_one(sequence);
   |                -------- value moved here
41 |     println!("{:?}", sequence);
   |                      ^^^^^^^^ value borrowed here after move

And that makes sense. By passing it into the append_one function just as it is (not a reference), it’s gone from the surrounding scope.

But what if I want to use it afterwards anyway? Maybe I could borrow a mutable reference instead of moving?

fn append_one(mut sequence: &Vec<u64>) {

let sequence = vec![1,2,3];
println!("{:?}", sequence);


error[E0596]: cannot borrow `*sequence` as mutable, as it is behind a `&` reference
  --> src/
35 |     fn append_one(mut sequence: &Vec<u64>) {
   |                                 --------- help: consider changing this to be a mutable reference: `&mut Vec<u64>`
36 |         sequence.push(1);
   |         ^^^^^^^^^^^^^^^^ `sequence` is a `&` reference, so the data it refers to cannot be borrowed as mutable

What I can do though, is return the sequence from append_one again:

fn append_one(mut sequence: Vec<u64>) -> Vec<u64> {

let mut sequence = vec![1,2,3];
sequence = append_one(sequence);
println!("{:?}", sequence);

And it works:

[1, 2, 3, 1]

I think what was confusing for me here is that this feels a lot more like “borrowing” in a real-world sense. The function append_one borrows the value, changes it a bit and returns it to the original owner. Although technically, there’s no reason why it needs to return the exact same vector and not a completely new one as long as it satisfies the Vec<u64> type signature. But Rust uses the term “borrowing” for passing references, usually for read-only access which isn’t an option here.

To add more chaos, in my head the metaphor for move semantics in Rust has become on of “eating”. Does this function eat this value? If yes, I need to move and not borrow it. So in a way I imagine my Rust programs as a bunch of tiny critters (crabs, of course) that feed each other snacks. Although, this metaphor breaks down once functions return the value they modified, or rather, I’d like to not take the metaphor that far …

In internet drama news, Twitter continues to unravel both in terms of people working there and as a technology product. Apparently two-factor authentication was or is flaky for some people, suspiciously right after Musk announced to shut down large parts of Twitter’s internal services that he deemed “bloat”. As someone who has worked as several companies that run more or less large sets of small services on their backend, I think it’s obvious that you can’t just turn off half of them without some major development effort to replace them. Even if they’re bloated, most of them often have some critical part to play.

There’s been reports of content leaking out from protected accounts which is particularly scary as many people use these to share very sensitive material with trusted people, e.g. nude photos or very intimate details about their personal lives.

With most, if not all, of the security staff at Twitter gone, it this is all very worrying.

It also seems like the culture at Twitter (the company) is becoming more authoritarian by the day. People are getting fired for very basic criticism and those who choose remain are sworn in on a very rough near-term future.

Is the world’s richest person the world’s worst boss? What it’s like working for Elon Musk is an impressive overview of Musk’s practices as a manager. You can basically take everything he does and do the exact opposite of you want to be at least a decent manager.

I Emailed My Doctor 133 Times: The Crisis In the British Healthcare System, the new video from PhilosophyTube, is a deep dive into how broken the UK’s healthcare system is for trans people (and others). It’s bad.

The “Pay For It” Scam goes into a common tactic used by conservative politicians and media whenever progressive politics that require government spending are on the table. But somehow the same people never bother when it’s about military or police budgets.

Goblin game review round-up from Polygon, just a delightful little thing about being an obnoxious little Goblin. “Hee-Hee Hoo-Hoo!”

Mastodon on your own domain without hosting a server is a neat little guid on how to use the Webfinger protocol to make yourself more easily discoverable on Mastodon and other Fedi services without having to host your own instance.

Twitter is Going Great! is a timeline of events in the unraveling of Twitter, inspired by Web 3 is Going Just Great.