A data race that doesn't compile
stmw
23 points
6 comments
June 26, 2026
Related Discussions
Found 5 related stories in 118.1ms across 11,625 title embeddings via pgvector HNSW
- Show HN: cuTile Rust: Safe, data-race-free GPU kernels in Rust melihelibol · 59 pts · June 16, 2026 · 50% similar
- Iddqd, or the hardest kind of unsafe Rust hasheddan · 24 pts · June 02, 2026 · 48% similar
- An incoherent Rust emschwartz · 160 pts · March 23, 2026 · 46% similar
- RX – a new random-access JSON alternative creationix · 53 pts · March 18, 2026 · 46% similar
- Lisp in the Rust Type System quasigloam · 33 pts · June 20, 2026 · 45% similar
Discussion Highlights (4 comments)
nynx
I don’t think this needed to be parallelized.
asdf88990
AI written article. I hate how I can quickly pick this up these days and I hate how I see it everywhere recently. If you don’t have time to write, I don’t have time to read it.
cptroot
I know this is a small point, but you likely mean "race condition" here. Rust already guarantees safe code to be free of "data races", and this blog post doesn't discuss unsafe in any way. Two other points that came up while I was reading: 1. I get that this is something you did once for an internal project, but this is what macros and derive_macros are made for. 2. The AI that you used to help write the post left its mark a little too deep. The cliched phrases make an appearance at the start of every section and it really starts to grate by the end.
ydj
Surely you can express this in C++ just as you could in rust…