Why We Didn't Rewrite Our Feed Handler in Rust
Posted3 months agoActive3 months ago
databento.comTechstory
calmmixed
Debate
20/100
RustPerformance OptimizationSystem Design
Key topics
Rust
Performance Optimization
System Design
The author explains why they chose not to rewrite their feed handler in Rust, sparking a discussion on the trade-offs between Rust and other languages for high-performance applications.
Snapshot generated from the HN discussion
Discussion Activity
Moderate engagementFirst comment
2h
Peak period
7
0-6h
Avg / period
4
Key moments
- 01Story posted
Oct 8, 2025 at 9:54 AM EDT
3 months ago
Step 01 - 02First comment
Oct 8, 2025 at 11:26 AM EDT
2h after posting
Step 02 - 03Peak activity
7 comments in 0-6h
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 10, 2025 at 3:50 PM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45516255Type: storyLast synced: 11/20/2025, 2:52:47 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
"Why we didn't rewrite our feed handler in Rust"
Anyway, I don't mean to nitpick; I know that what's given in TFA are high level examples representing broader classes of concerns, but I thought this one in particular was interesting for having some decent alternatives.
However, the other issues they mention hit some well-known limitations of Rust, which don't always have a simple satisfactory solution. It's a valid criticism.
With a bit of `unsafe`, it's easy to force through self-referential structs incorrectly and violate exclusive ownership/aliasing rules (that's UB, in Rust!). Sometimes such code can be reorganized to avoid self-referential structs. With enough `unsafe` dark arts it's also possible to properly handle some self-references. However, in general it's typically a false positive in the borrow checker's model, and an annoying limitation.
For 2, I believe the pattern would be to make a generic version of the data structure as its own crate, with all the required unsafe stuff in there, properly tested and hidden behind a safe interface. Obviously that does require the data structure to be well defined and for you to know upfront what all the internal references and transformations are going to need to be (but honestly... it's probably good for that to be the case regardless).
I still find "instead of a little unsafe, we choose all unsafe everywhere" to be kinda silly reasoning.