Valentyn Kit 🦀 | Rust · Solana

I read 8 MB of a file through mmap, and Linux pulled a whole gigabyte off the disk to serve it. Same reads with plain pread: exactly 8 MB. My first guess was a bug in my benchmark. A miss through a mapping is a page fault, and the fault doesn't fetch one page. It reads a window of the file around it, 4 MiB on this VM, betting you'll walk the neighbours next. On a scan, that bet pays. At random, every miss drags in a window you never touch. 2,000 random reads of a cold file: - pread: 8 MB from disk - mmap: a whole gigabyte, each read about 18x slower - mmap after madvise(MADV_RANDOM): 8 MB again Nothing in your code tells the kernel whether you scan or jump. It guesses, and a cold start pays for the guess.

io_uring hands every read back with a correlation ID, for the same reason your message queue does. Writing my own ring this week, one field in each request is there only for me: user_data. The man page says why. Requests "can complete in any order", and this field "can be used to correlate a submission with a completion". - you submit a batch of reads -> they can all be in flight at once - each finishes when its bytes are ready -> not in the order you asked - the result carries no file and no offset -> only the outcome and your tag - the kernel never reads the tag -> it just hands it back, untouched In my reader the tag is the index of the buffer the read went into. One integer, and you know which buffer holds the bytes. That is the request ID on a queue message. The reply shows up whenever it shows up, and the ID is how you find who was waiting for it. It clicked in the loop that collects results: take the tag, index the buffers, move on. I had written that lookup before, against a queue. The whole ring, piece by piece, is in this week's Article.

At this desk, nvim won't let me tap j over and over. It's a plugin I set to block, not warn: repeat a key and it stops me until I use a real motion. Sit idle in insert mode for five seconds and it kicks me back out. I set it up to annoy me, and it works.

Every Rust panic prints a number after the thread name, and until this month nothing in your own code could produce it. I read that number for years assuming it was kept somewhere. It is not. Why no thread handle could hand it to you: - the handle is built by the spawning thread -> it exists before the thread does - spawn hooks already hold it -> the thread it names may not have started - it may not keep the native thread pointer -> that goes invalid the moment a thread is joined or detached - and the handle outlives both -> holding one would be a promise the library cannot keep So nobody can ask on a thread's behalf. My patch merged in std this month and turns it around: each thread writes its own id into a cell that takes one value, on its way in, before your code runs. What that buys, and what it does not: - a log line carrying the id the row in top shows - the same number a debugger and a crash log print - ask before the thread starts -> nothing back - the child of a fork still reports the parent's thread -> it is never re-read - so the docs scope it: logging, never identity What do you log when a thread starts?

A model that CANNOT write a single sentence just organized 323 projects about itself. This is the Jev list. Indexed by Jev. Searched by Jev. Every project answers 59 typed questions and gets sorted by probability, not by vibes. 254 repos. One live radar. Zero LLM prose.

Ranges are patterns in Rust: match n { 0 => "zero", 1..=9 => "digit", _ => "big", } No if-else chain, and the compiler proves every case is covered before it runs.

I built a Redis clone in C. Now I'm rebuilding the same thing in Rust. Redoing a project that already runs sounds like busywork. It's the fastest way I've learned a language.

This Rust compiles clean. It panics the first time you run it. Where's the bug?

Just bought 49’ monitor to see Rust borrow checker complaining in one line.

"Rust is hard" is mostly the first time a language makes you say who owns your data. In C, nothing forces the answer. Who frees this pointer? You carry it in your head across the whole file.

To understand Rust, I spent this week writing C on purpose. Every Rust feature is the answer to a specific C bug. You don't feel the answer until you've shipped the bug. So I'm shipping them on purpose. What did you only understand after doing it the hard way?

Half of "Rust is too strict" is people finding out their C code was never correct, only lucky. The borrow checker isn't adding rules. It's enforcing the one your old compiler let you ignore until production. #rustlang

Ran out of file descriptors in Rust and the error came back as Uncategorized. To even know what happened you had to dig into raw_os_error(). So I fixed it in rust-lang. Second PR I've landed there, both in the low-level io.

Rust's std probes pidfd once, then caches the result process-wide. EMFILE (per-process fd limit): transient, re-probe later. ENFILE/ENOMEM: cached 'no pidfd' forever, even after fds freed. Same cause, opposite handling. Now fixed in rust std. #rustlang

The Rust borrow checker isn't a style cop. It's a use-after-free detector that runs before your program does. The same move in C compiles fine and can hand you a dangling pointer. Rust refuses to build it.