{"slug": "miri", "name": "Miri", "category": "other", "category_name": "Other software", "description": "", "recommenders": 4, "commenters": 5, "warners": 0, "score": 3.794, "rising": 1.02, "first": "2026-01-02", "latest": "2026-09-30", "why": "I highly recommend running your tests through Miri (cargo miri nextest) and seeing what spills out.", "why_is_quote": true, "has_verdict": false, "sentiment": {"recommend": 5, "neutral": 0, "compare": 1, "warn": 0}, "spark": [0, 0, 2, 0, 0, 0, 0, 0, 1, 0, 2, 0], "listed": true, "loved": [], "caveat": "", "short_quote": "I highly recommend running your tests through Miri (cargo miri nextest) and seeing what spills out.", "icon": true, "domain": null, "github_repo": "github.com/rust-lang/miri", "official_url": "https://github.com/rust-lang/miri", "pricing": "", "aliases": ["Miri", "miri"], "verdict": null, "praise": [{"label": "", "summary": "", "quotes": [{"id": 798598657, "item_id": 49912416, "url": "https://news.ycombinator.com/item?id=49912416", "by": "singron", "date": "2026-09-30", "stance": "recommend", "quote": "If you use rust, miri and loom both have analyzers that can check some non-sequentially-consistent behavior", "excerpt": "I love this. This is great to read if you are trying to use TLA+ for something. In a different vein, another thing TLA+ isn't great at is modeling atomics and in particular weak-memory semantics or anything that's not sequentially consistent. If you translate your algorithm to pcal, it will run as if it was sequentially consistent. If you need to model non-sequential-consistency, then that needs to be spelled out wit", "context": "", "use_case": "checking weak-memory behavior in Rust", "switched_from": "", "story": "What TLA+ can and can't check"}, {"id": 793825153, "item_id": 49614072, "url": "https://news.ycombinator.com/item?id=49614072", "by": "lowbloodsugar", "date": "2026-09-08", "stance": "recommend", "quote": "test with miri", "excerpt": "Take a look at triomphe's ArcUnion and extrapolate from there. Basically make a crate for just your 64bit union type, do it unsafe there, test with miri, and now you have a safe 64bit type you can use with match. You're happy digging around assembly so this is well within your wheelhouse. The only challenge will be if you do use miri to verify then you need to use the 'provenance-preserving' pointer adjusting functio", "context": "", "use_case": "verifying unsafe Rust", "switched_from": "", "story": "Replacing a Rust Enum with a 64-Bit Word Made My Interpreter 17% Faster"}, {"id": 783090336, "item_id": 48943146, "url": "https://news.ycombinator.com/item?id=48943146", "by": "lowbloodsugar", "date": "2026-07-16", "stance": "recommend", "quote": "miri the fuck out of that, and then just consume it in your application.", "excerpt": "> though (more on this later) and we ended up with about 1,200 uses of unsafe (out of our 300K lines of Rust code Vs >Rust code has a different source of memory-safety gaps: the unsafe sections that nearly every Rust program has somewhere in its dependencies. Unsafe Rust has all the memory unsafety risk of ReleaseFast Zig code, but none of the runtime checks to catch issues during development Well if ReleaseFast woul", "context": "", "use_case": "checking unsafe Rust code", "switched_from": "", "story": "How Our Rust-to-Zig Rewrite Is Going"}, {"id": 743493728, "item_id": 46468358, "url": "https://news.ycombinator.com/item?id=46468358", "by": "mmastrac", "date": "2026-01-02", "stance": "recommend", "quote": "Unsafe code absolutely needs Miri if the code paths are testable.", "excerpt": "I used Miri for some key deno libraries and spent a fair bit of time cleaning up the violations. Many of them were real unsoundness bugs due to reference aliasing. Unsafe code absolutely needs Miri if the code paths are testable. If not all code is Miri-compatible, it's worth restructuring it so you can Miri test as much as possible. Note that Miri, Valgrid and the LLVM sanitizers all compliment each other and it's r", "context": "worked on deno libraries", "use_case": "detecting undefined behavior in unsafe Rust", "switched_from": "", "story": "Miri: Practical Undefined Behavior Detection for Rust [pdf]"}, {"id": 743493312, "item_id": 46468332, "url": "https://news.ycombinator.com/item?id=46468332", "by": "landr0id", "date": "2026-01-02", "stance": "recommend", "quote": "I highly recommend running your tests through Miri (cargo miri nextest) and seeing what spills out.", "excerpt": "If you have a codebase that uses unsafe, I highly recommend running your tests through Miri (cargo miri nextest) and seeing what spills out. I ran tests for a codebase at work through Miri a while ago and found a couple of distinct classes of UB: https://github.com/rust-lang/miri/issues/1807#issuecomment-845425076 These can be summarized as: 1. Converting a reference to the first field of a struct to a pointer of its", "context": "works on a codebase using unsafe Rust", "use_case": "detecting undefined behavior in Rust", "switched_from": "", "story": "Miri: Practical Undefined Behavior Detection for Rust [pdf]"}]}], "caveats": [], "who": [{"by": "mmastrac", "context": "worked on deno libraries", "url": "https://news.ycombinator.com/item?id=46468358", "date": "2026-01-02"}, {"by": "landr0id", "context": "works on a codebase using unsafe Rust", "url": "https://news.ycombinator.com/item?id=46468332", "date": "2026-01-02"}], "tags": [], "use_cases": ["checking weak-memory behavior in rust", "rust verification", "verifying unsafe rust", "checking unsafe rust code", "detecting undefined behavior in unsafe rust", "detecting undefined behavior in rust"], "compared": [], "makers": [], "threads": [{"url": "https://news.ycombinator.com/item?id=46414152", "title": "Miri: Practical Undefined Behavior Detection for Rust [pdf]", "mentions": 2}, {"url": "https://news.ycombinator.com/item?id=49909056", "title": "What TLA+ can and can't check", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=49700153", "title": "Developing provably correct Rust code with Verus", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=49575914", "title": "Replacing a Rust Enum with a 64-Bit Word Made My Interpreter 17% Faster", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=48933149", "title": "How Our Rust-to-Zig Rewrite Is Going", "mentions": 1}], "sentiment_by_month": {"2025-11": {}, "2025-12": {}, "2026-01": {"recommend": 2}, "2026-02": {}, "2026-03": {}, "2026-04": {}, "2026-05": {}, "2026-06": {}, "2026-07": {"recommend": 1}, "2026-08": {}, "2026-09": {"recommend": 2, "compare": 1}, "2026-10": {}}, "quotes": [{"id": 798598657, "item_id": 49912416, "url": "https://news.ycombinator.com/item?id=49912416", "by": "singron", "date": "2026-09-30", "stance": "recommend", "quote": "If you use rust, miri and loom both have analyzers that can check some non-sequentially-consistent behavior", "excerpt": "I love this. This is great to read if you are trying to use TLA+ for something. In a different vein, another thing TLA+ isn't great at is modeling atomics and in particular weak-memory semantics or anything that's not sequentially consistent. If you translate your algorithm to pcal, it will run as if it was sequentially consistent. If you need to model non-sequential-consistency, then that needs to be spelled out wit", "context": "", "use_case": "checking weak-memory behavior in Rust", "switched_from": "", "story": "What TLA+ can and can't check"}, {"id": 795854496, "item_id": 49740906, "url": "https://news.ycombinator.com/item?id=49740906", "by": "63", "date": "2026-09-17", "stance": "compare", "quote": "I've not used any of them so I'll refrain from trying to differentiate them.", "excerpt": "If you found this interesting, you may also be interested to hear about some related projects with similar goals/scopes: Miri[0], Kani[1], and Creusot[2]. There looks to be some significant overlap between Verus, Kani, and Creusot but I've not used any of them so I'll refrain from trying to differentiate them. [0]https://github.com/rust-lang/miri [1]https://github.com/model-checking/kani [2]https://github.com/creusot", "context": "", "use_case": "Rust verification", "switched_from": "", "story": "Developing provably correct Rust code with Verus"}, {"id": 793825153, "item_id": 49614072, "url": "https://news.ycombinator.com/item?id=49614072", "by": "lowbloodsugar", "date": "2026-09-08", "stance": "recommend", "quote": "test with miri", "excerpt": "Take a look at triomphe's ArcUnion and extrapolate from there. Basically make a crate for just your 64bit union type, do it unsafe there, test with miri, and now you have a safe 64bit type you can use with match. You're happy digging around assembly so this is well within your wheelhouse. The only challenge will be if you do use miri to verify then you need to use the 'provenance-preserving' pointer adjusting functio", "context": "", "use_case": "verifying unsafe Rust", "switched_from": "", "story": "Replacing a Rust Enum with a 64-Bit Word Made My Interpreter 17% Faster"}, {"id": 783090336, "item_id": 48943146, "url": "https://news.ycombinator.com/item?id=48943146", "by": "lowbloodsugar", "date": "2026-07-16", "stance": "recommend", "quote": "miri the fuck out of that, and then just consume it in your application.", "excerpt": "> though (more on this later) and we ended up with about 1,200 uses of unsafe (out of our 300K lines of Rust code Vs >Rust code has a different source of memory-safety gaps: the unsafe sections that nearly every Rust program has somewhere in its dependencies. Unsafe Rust has all the memory unsafety risk of ReleaseFast Zig code, but none of the runtime checks to catch issues during development Well if ReleaseFast woul", "context": "", "use_case": "checking unsafe Rust code", "switched_from": "", "story": "How Our Rust-to-Zig Rewrite Is Going"}, {"id": 743493728, "item_id": 46468358, "url": "https://news.ycombinator.com/item?id=46468358", "by": "mmastrac", "date": "2026-01-02", "stance": "recommend", "quote": "Unsafe code absolutely needs Miri if the code paths are testable.", "excerpt": "I used Miri for some key deno libraries and spent a fair bit of time cleaning up the violations. Many of them were real unsoundness bugs due to reference aliasing. Unsafe code absolutely needs Miri if the code paths are testable. If not all code is Miri-compatible, it's worth restructuring it so you can Miri test as much as possible. Note that Miri, Valgrid and the LLVM sanitizers all compliment each other and it's r", "context": "worked on deno libraries", "use_case": "detecting undefined behavior in unsafe Rust", "switched_from": "", "story": "Miri: Practical Undefined Behavior Detection for Rust [pdf]"}, {"id": 743493312, "item_id": 46468332, "url": "https://news.ycombinator.com/item?id=46468332", "by": "landr0id", "date": "2026-01-02", "stance": "recommend", "quote": "I highly recommend running your tests through Miri (cargo miri nextest) and seeing what spills out.", "excerpt": "If you have a codebase that uses unsafe, I highly recommend running your tests through Miri (cargo miri nextest) and seeing what spills out. I ran tests for a codebase at work through Miri a while ago and found a couple of distinct classes of UB: https://github.com/rust-lang/miri/issues/1807#issuecomment-845425076 These can be summarized as: 1. Converting a reference to the first field of a struct to a pointer of its", "context": "works on a codebase using unsafe Rust", "use_case": "detecting undefined behavior in Rust", "switched_from": "", "story": "Miri: Practical Undefined Behavior Detection for Rust [pdf]"}]}