Hi there,
You don't know me yet, so here's a short version: I'm a backend engineer, and I'm building an application that connects patients to medical laboratories for home sample collections. The flow goes: book an appointment for a lab test, a lab's phlebotomist comes to you instead of the other way around, they collect the sample and flag it as done, and the lab handles the results.
And I'm building the backend in Rust.
This is the part I'm still getting used to saying out loud. A friend talked me into it, and going in, my hesitation wasn't about Rust's reputation for being hard (though that's real); it was that I've spent the last few years comfortable in Python and Node, where a lot of what Rust asks you to think about explicitly (memory, ownership, what happens when two things touch the same data at once) is either invisible or someone else's problem. Picking Rust for a project that's going to move real data (patient pay in-app, labs get paid once a sample is collected, and patient details) felt really like a strange time to also be learning a new language.
But this is why I picked it, though. This is a serious project; it has real state to get right (an appointment moving through booked, confirmed, collected, paid-out) and real consequences if I get the money-handling wrong. Rust's type system makes it hard to represent an invalid state, and its compiler makes it hard to ignore an error path.
I am starting a series where I document my journey through building this software with Rust, and this is the first page in that series.
If you want to follow along with the language itself: The Rust programming language.
Thank you, and catch you on the next one.
Top comments (0)