A few times I've discovered code that uses tokio File I/O in a way that is unreliable. This is because there's a bit of a footgun in the implementation of how File writes occur in the tokio runtime.
If you use tokio::fs::File in your code, you should probably know about this hazard, to avoid some unpleasant surprises.
This is something I built for my own use, as a reference I can use to remember some of the properties of the Rust channel implementations I use most often.
Which channels implement fallible send? Which one implements an async sender and blocking receiver? What do I lose if I make my channel bounded size? These are the questions I ask myself when picking out an mpsc channel implementation.
I've often wondered about the differences between lazy_static and once_cell, and in Rust 1.70 and 1.80 the standard library is gaining the ability to create one-time-initialized values.
Most big projects end up using one of these crates, because lazy initialization is a very convenient way to implement almost-const global values that can't actually be const-initialized, because they need heap memory (e.g. String or Vec), read files or environment variables, or use types that don't have const initializers yet.
But how do they work? Let's spend some time looking at the differences between these three implementations.
The other day I made a joke on twitter, and learned some interesting things about raw pointers in Rust.
The abridged joke goes something like this:
Yosh: What do you mean Rust doesn't ship with
randbuilt-in?
Me: ASLR to the rescue!
fn main() { let rand = main as usize; dbg!(rand); }
I always forget the exact syntax to do shallow clones in git. I recently tracked it down for a few different use cases, so I thought I'd document them in one place since the documentation is kind of diffuse.