Steve Klabnik recently wrote about whether out parameters are idiomatic in Rust. The post
ends by showing a snippet of code: a generic function, with a non-generic function inside of
it which contains the actual implementation. Steve says this pattern may warrant its own post,
so here is that post, where I’ll explain why this inner function is useful, discuss the
trade-offs of doing it, and describe why this pattern will hopefully not be necessary in
Rust gets a lot of first impression posts. For people in the community, reading
those posts can often be frustrating, with factual errors leaving people concerned
that others will get the wrong impression. For people outside the community, they
may be unsure of how much said is true, or how to read these posts effectively. In
this post, I outline how I think about first impression posts, and why I recommend
reading them the same way.
Foreign Function Interfaces (FFI) are a core mechanism for enabling integration of
new languages into existing codebases or building on existing libraries. That said,
the term “FFI” is often overloaded in ways that may be unclear or ambiguous, and the
area can seem overwhelming to approach. In this post, I explain the two “directions”
of FFI, some patterns for how FFI in each direction is handled in Rust and further
break down some FFI design approaches.
Rust has two major mechanisms for delegating logic: enums and trait objects,
and it may be unclear when to use one or the other. In this post, I will
walk through how each works, what the tradeoffs are, and how to choose the
right option for your code.
The Rust compiler ships with a number of useful lints on by default,
and many use Clippy to provide additional lints. It’s less well known
that the Rust compiler ships with some useful lints which are set to
allow by default, meaning they don’t generate warnings. In this post,
I’ll explain what each of these lints does, and why it might be useful.