Top all-time · #558
ralfj.de
Personal blog · ralfj.de/blogprogramming
ralfj.de is a personal blog at ralfj.de about programming. Since 2015, 106 different Hacker News readers have linked it 160 times, most often “There is no memory safety without thread safety”. No feed was found, so read it on the site itself.
Sometimes recommended · 6 of 40 sampled comments recommend it?
Why HN links it
HN readers link Ralf Jung's blog on C and Rust semantics: pointer provenance, undefined behaviour, uninitialized memory and data races. Most links cite posts as support; a few call them thorough or high-quality.
- Recommended for · 6 comments
- Called a "very thorough explanation" and "high-quality"; one commenter says Ralf "explains it better than me" and that they enjoy a writeup.
Summarised by Claude from a sample of 40 HN comments that link here. Each comment is marked recommending, critical or neutral (citing without judging); how this works.
Most-linked posts?
- There is no memory safety without thread safety13 people · 15 mentions · first linked 2025-07-24
- Pointers Are Complicated II, or: We need better language specs13 people · 15 mentions · first linked 2020-12-14
- “What the Hardware Does” Is Not What Your Program Does: Uninitialized Memory13 people · 13 mentions · first linked 2019-07-14
- Pointers Are Complicated, or What’s in a Byte?11 people · 13 mentions · first linked 2018-07-24
- From Stacks to Trees: A new aliasing model for Rust9 people · 9 mentions · first linked 2023-06-02
- Pointers Are Complicated III, or: Pointer-integer casts exposed8 people · 9 mentions · first linked 2022-04-11
- Thoughts on Compile-Time Function Evaluation and Type Systems5 people · 7 mentions · first linked 2018-07-19
- How to use storytelling to fit inline assembly into Rust5 people · 6 mentions · first linked 2026-03-13
- Why even unused data needs to be valid in Rust5 people · 5 mentions · first linked 2020-07-16
- Do we really need undefined behavior?5 people · 5 mentions · first linked 2021-11-26
What Hacker News says?
That work is ongoing even if the RustBelt project ended. It's been a / the major focus of Ralf Jung's work for over 10 years and he's an assistant professor at ETH Zürich now, still working on it. https://www.ralfj.de/blog/categories/research.html
Comment linking /blog/categories/research.html
on “11 year old unsoundness bugs found in Rust borrow checker”Submitted There is no memory safety without thread safety as a story · 456 points
HN discussionIt's a work in progress. The Reference ( https://doc.rust-lang.org/reference ) is slowly getting more complete over time. Other ongoing efforts include a-mir-formality ( https://github.com/rust-lang/a-mir-formality ), minirust ( https://github.com/minirust/minirust ), the FLS ( https://github.com/rust-lang/fls ), and Rust via Desugarings ( https://nadrieril.github.io/rust-via-desugarings/ ). But writing a 100% compl…
Comment linking /blog/2020/12/14/provenance.html
on “11 year old unsoundness bugs found in Rust borrow checker”Submitted MiniRust as a story · 284 points
HN discussionI agree that it is a bad idea to describe rust this way but they likely meant memory safety as used in https://www.ralfj.de/blog/2025/07/24/memory-safety.html . Meaning that shared mutable is thread unsafe, I am unsure about Java and JavaScript but I think that almost every language on the popular memory safe list fails this test . Again the statement is probably still untrue and bad marketing, but I suspect this ki…
Comment linking /blog/2025/07/24/memory-safety.html
on “Garage – An S3 object store so reliable you can run it outside datacenters”Submitted Pointers Are Complicated II, or: We need better language specs as a story · 262 points
HN discussionIf no references are involved, writing unsafe Rust is significantly easier than writing correct C, because the semantics are much clearer and easier to find in the documentation, and there's no insane things like type-based aliasing rules. If references are involved, Rust becomes harder, because the precise semantics are not decided or documented. The semantics aren't complicated ; they're along the lines of "while…
Comment linking /blog/
on “Open-source Zig book”Submitted Pointers Are Complicated II, or: We need better language specs (2020) as a story · 169 points
HN discussionRecent blog post from Ralf Jung providing some extra context: https://www.ralfj.de/blog/2025/07/07/tree-borrows-paper.html Bonus: recent talk from Ralf Jung on his group's efforts to precisely specify Rust's operational semantics in executable form in a dialect of Rust: https://youtube.com/watch?v=yoeuW_dSe0o
Comment linking /blog/2025/07/07/tree-borrows-paper.html
on “Tree Borrows”Submitted Sandboxing all the things with Flatpak and BubbleBox as a story · 166 points
HN discussionWell, you've demonstrated that memory addresses aren't that hard. But you've also demonstrated how easy it is to get undefined behavior in C programs. C's pointers aren't memory addresses. Ok, they tend to be represented as such at run time, but that's not what the spec actually says the are. And as far as compiler authors are concerned, they can do anything they want as long as it's within spec. Further, the spec e…
Comment linking /blog/2020/12/14/provenance.html
on “Beej’s Guide to C Programming [pdf]”Submitted Pointers Are Complicated III, or: Pointer-integer casts exposed as a story · 129 points
HN discussionPointers seem easy until you understand the pointers you're working with do not correspond with the basic hardware model you have in mind: https://www.ralfj.de/blog/2018/07/24/pointers-and-bytes.html https://www.ralfj.de/blog/2020/12/14/provenance.html https://www.ralfj.de/blog/2019/07/14/uninit.html
Comment linking /blog/2019/07/14/uninit.html
on “Beej’s Guide to C Programming [pdf]”Submitted “What the Hardware Does” Is Not What Your Program Does: Uninitialized Memory as a story · 124 points
HN discussionI feel like I'm defending Go constantly these days. I don't even like Go! Go can already ensure "consistency of multi-word values": use whatever synchronization you want. If you don't, and you put a race into your code, weird shit will happen because torn reads/writes are fuckin weird. You might say "Go shouldn't let you do that", but I appreciate that Go lets me make the tradeoff myself, with a factoring of my choo…
Comment linking /blog/2021/11/18/ub-good-idea.html
on “There is no memory safety without thread safety”Submitted Pointers Are Complicated, or What’s in a Byte? as a story · 119 points
HN discussion> There is plenty of undefined behavior that can't lead to violating memory safety. For example, in many languages, argument evaluation order is undefined. If you have some code like: You are mixing up non-determinism and UB. Sadly that's a common misunderstanding. See https://www.ralfj.de/blog/2021/11/18/ub-good-idea.html for an explanation of what UB is, though I don't go into the distinction to non-determinism th…
Comment linking /blog/2021/11/18/ub-good-idea.html
on “There is no memory safety without thread safety”Submitted Stacked Borrows: an aliasing model for Rust as a story · 91 points
HN discussionhttps://www.ralfj.de/blog/2025/07/24/memory-safety.html Go is by default not thread safe. Here the author shows that by looping for { globalVar = &Ptr { val: &myval } globalVar = &Int { val: 42 } } You can create a pointer with value 42 as the type and value are two different words and are not updated atomically So I guess go is easier to write, but not with the same level of safety
Comment linking /blog/2025/07/24/memory-safety.html
on “Thoughts on Go vs. Rust vs. Zig”Submitted Pointers Are Complicated, Or: What's in a Byte? (2018) as a story · 85 points
HN discussionUsing data races: https://www.ralfj.de/blog/2025/07/24/memory-safety.html
Comment linking /blog/2025/07/24/memory-safety.html
on “Rust in Android: move fast and fix things”Submitted How MutexGuard Was Sync When It Should Not Have Been as a story · 78 points
HN discussionRaces can be memory safe (they are in Java and Ocaml), but in Go they can indeed cause UB. https://go.dev/ref/mem#restrictions:~:text=such%20races,corr... https://www.ralfj.de/blog/2025/07/24/memory-safety.html (I don't agree with everything here, but it's a very thorough explanation)
Comment linking /blog/2025/07/24/memory-safety.html
on “Platform-independent SIMD in Go”Submitted The Scope of Unsafe as a story · 78 points
HN discussionIt's not memory safe: https://www.ralfj.de/blog/2025/07/24/memory-safety.html
Comment linking /blog/2025/07/24/memory-safety.html
on “Go Concurrency Distilled”Submitted Do we really need undefined behavior? as a story · 54 points
HN discussionJava is doing it better (virtual threads + structured concurrency + immutable records and immutable value types). Not to mention golang is not memory safe: https://www.ralfj.de/blog/2025/07/24/memory-safety.html
Comment linking /blog/2025/07/24/memory-safety.html
on “Go Concurrency Distilled”Submitted Thoughts on Compile-Time Function Evaluation and Type Systems as a story · 13 points
HN discussionI think the practical issues you describe like rebuilds of packages and so on are very real if we're talking about general adoption. But if we're talking about recompiling a handful of SUID programs which make up a TCB then I think a proposition like that has a lot of merit and can't be easily dismissed. Any C code that needs changing to deal with fat-pointers is probably already UB in C (or at best, has some implem…
Comment linking /blog/2020/12/14/provenance.html
on “Heap-based buffer overflow in Sudo”Submitted Pointers Are Complicated III, or: Pointer-integer casts exposed as a story · 11 points
HN discussion
