Sometimes read Rust like a Chinese Character — Dawaba

← index

Some Context

I've chosen Rust as my second language after spending a couple of years with Python as my primary, nearly the last two (till date) of which has required me to use Python in soon-to-be production software. I've now experienced firsthand a lot of the "issues" commonly debated in online software communities regarding Python's limitations. Having felt these friction points in real-world contexts, I wouldn't call them "language issues" so much as non-ideal use cases. It's like using a flathead screwdriver to twist in a star-head screw: you can get it done, but you won't enjoy it, and it won't feel natural. I wouldn't call that a limitation of the screwdriver itself. I still love the tool, and I still love Python very much.

But as much as I love the Python programming language, there are just some things my darling can't handle or teach me. There are now parts of my codebase that I know will probably hold up under adversarial conditions, but I just don't enjoy reading them anymore.

Why Rust? Fuck if I know. It's a compiled, memory-safe systems language, so it's pretty fast as a consequence. It's also relatively young, meaning there's no cruft from legacy language designs and it's learnt their lessons. Honestly, it had me at "compiled, memory-safe systems language." There's really no need to overthink picking a second language as long as the secondary language has philosophies as directly in opposition to the primary language as possible and it's production capable in contexts beyond the capabilities of your primary language. That's all anyone needs to make a choice... unless your employer says otherwise, I guess.

The Moonlanding Encounter

Now, obviously, when you're learning a second language, you'd want to learn it in reference to your first, slowly carving out the similarities and differences between the two. And so, rather than starting with the canonical Rust Book, I set out to find a quick A-Z Python-to-Rust resource. I wanted to build an initial intuition about the language before I did a proper deep-dive.

I found this Microsoft resource, and as I was studying, I came across my first major "wtf" on my crossover from Python to Rust. Consider this:

if let Some(x) = optional_value {<br>println!("{}", x);<br>You see, whenever I read a piece of code, I try to intuit the intent... And a pretty solid assumption I have about programming languages is that they're structurally designed to be read from left to right. Therefore, every keyword and variable (let's call them "terms") in a single statement, should technically be in a logically 'complete' state relative to the previous terms until the end of that statement, typically delimited by a semicolon or the start of a block (like a curly bracket {...} in Rust or a newline indentation in Python).

At least, that’s what I thought, coming from Python as my primary language.

Reading the statement above, I kept mentally running into a wall trying to figure out what Some(x) meant relative to the conditional assignment if let that preceded it. This was my "moonlanding" encounter with Rust, and I was diving in with a lot of prior assumptions. Lucky me, I read the warning label, 'RUST IS DIFFERENT! '

At first, I wondered if it was a function call... But how could you have a function call (or any kinda evaluation infact) on the left side of an assignment statement? That is quite literally a mathematical violation of the concept of assignment. Looking backwards from Some(x), it didn't make sense, and tacking on = optional_value {...} didn't help either. What was the evaluation flow here?

Ohkay, ohkay... Let's start with what we think it should be. So, if we ignore the problematic Some() on the left side and just keep if let x = optional_value {...}, it suddenly makes sense. It seems to say: "Let x be assigned the value of optional_value," and then, "if x (is truthy), execute the block."

In Python, combining assignment and conditional evaluation in a single line is pretty normal, thanks to a certain tusked operator we'll discuss later in this article. And we often do "truthy" or "falsy" evaluations on variables:

# Python's approach to truthy evaluation<br>user_id = get_cached_id()<br>if user_id:<br>print(f"User logged in: {user_id}")<br>Now we have a theory of what that first line in Rust was trying to do... an assignment statement of some sort. But the statement isn't if let x = optional_value. We still had to figure out what Some(x) meant and what the heck it was doing on the left side of an assignment operator.

Detour: What is Some()?

I found that Some() isn’t a keyword or a function, regardless of the parentheses syntax. It’s a variant (or member) of a built-in Rust enum called Option.

// Here's the Option enum<br>enum Option {<br>Some(T),<br>None,

Explainer: An enum (enumeration) is a data type that lets you give names to a small, fixed set of possible values that all belong to the same category. A variant...