For most of my professional experience, I have been writing production code in both Haskell and Rust, primarily focusing on web services, APIs, and HTTP stack development. My journey started with Haskell, followed by working with Rust, and most recently returning to the Haskell ecosystem.

This experience has given me perspective on both languages' strengths and limitations in real-world applications. Each language has aspects that I appreciate and miss when working with the other. This post examines the features and characteristics that stand out to me in each language.

impl<T: TraitA> MyTrait for T { ... }
impl<T: TraitB> MyTrait for T { ... }

After learning so much about the niche Rust topic of temporaries, I'm determined to also burden you with this unholy knowledge, if you're just willing to read a few thousand words on it.

The discussion is long-running enough that I’ve seen some arguments show up again and again in various forms from various people, over a span of a decade.

<...>

Today, I’ll focus on three proposals that people bring up a lot in associated discussions, and try to explain why these proposals wouldn’t work for the Rust language.

<...>

Which leads us to Rust 1.87, which came out 3654 days after that date, which, through the magic of off-by-one errors, happens to be precisely 10 years after the release of Rust 1.0.

In this post, I want to make two arguments:

1. That the borrowchecker causes serious ergonomic problems for Rust.

2. That the role of the borrowchecker in Rust's safety is overstated.

Perversely, because Rust's lifetime riddles are challenging, they are sort of fun. I believe that partly explains why so many people don't seem to mind them. Instead of thinking about how to write my code to solve the scientific problems I'm being paid to solve, I have to think about how to write it to please the borrowchecker. The latter is usually more tractable, limited in scope, have clearer requirements and is more 'puzzle-like'. In that sense, Rust enables escapism: When writing Rust, you get to solve lots of 'problems' - not real problems, mind you, but fun problems.

I’ve just completed reading an amazingly well-written book called “Refactoring to Rust” by Lily Mara and Joel Holmes, published recently by Manning Publications. I’m pretty sure that the book was supposed to be called “Rewrite it to Rust,” but then someone realized that this is already a meme, so it’d be too much.

Yet, the goal is exactly that – to teach folks how to gradually introduce Rust components to their existing codebases written in C/C++, Java, Python, or JavaScript. Such a goal reflects the intended audience: developers in those languages with little or no knowledge of Rust. One interesting thing, though, is that even Rust professionals might find a lot of interesting details about Rust itself, especially if they are not experienced in such areas as FFI (Foreign Function Interface), Rust-Python interoperability, or WebAssembly – those are the key topics of the book.