b=e=>document.body.innerHTML=m(73,e||[~9,..."1172711",~9].map(j=>m[i-=j]?++e:i).map(j=>b(b[i=j]^1|e),b[i]=!m[O--,i]*~e));b(m=t=>t--?`<a onmouseup=b(b[i=${t}]^=event.which)>${t%9?"*#F"[x=b[t]??=(O-=m[t]=Math.random()<.1,1)]??~x:"<p>"}`+m(t):O,O=64)

If your disk isn’t critically struggling with available space, are you even #Rusting?

I’m the main author of iddqd, a Rust library for maps (named after the Doom cheat code) where keys are borrowed from values. <...>

iddqd consists of a fair amount of unsafe code underneath. There’s been some recent concern over the amount of unsafe code in Rust rewrites, so I thought I’d write about some of the unsafe code in iddqd and how we try to tame it.

This is a story of how I tried to compute a * b + c, and found that Rust and musl libc get it subtly wrong.

I'll go into some detail on how the interpreter was rewritten to switch from a stack-based design like CPython, to a register-based design like Lua, and optimized to deliver some surprising, and I think pretty impressive results. One thing I'll say right away is that if you care about interpreter performance, you probably should not be writing stack-based bytecode interpreters in 2026.