{"slug": "rustc", "name": "rustc", "category": "dev-libs", "category_name": "Libraries and frameworks", "description": "", "recommenders": 3, "commenters": 20, "warners": 4, "score": 2.112, "rising": -0.98, "first": "2025-11-11", "latest": "2026-10-23", "why": "Those are all what Rust developers (who were or still are quite advanced C++ devs, btw, not people who are afraid of using raw ptrs) get freely from the Rust compiler.", "why_is_quote": true, "has_verdict": false, "sentiment": {"recommend": 3, "neutral": 13, "compare": 2, "warn": 4}, "spark": [0, 0, 1, 1, 0, 0, 0, 1, 0, 0, 0, 0], "listed": true, "loved": [], "caveat": "", "short_quote": "Those are all what Rust developers (who were or still are quite advanced C++ devs, btw, not people who are afraid of using raw ptrs) get freely from the Rust compiler.", "kind": "", "icon": true, "domain": null, "github_repo": "github.com/rust-lang/rust", "official_url": "https://www.rust-lang.org", "pricing": "", "aliases": ["rustc", "Rust", "Rust compiler"], "verdict": null, "praise": [{"label": "", "summary": "", "quotes": [{"id": 776756304, "item_id": 48547269, "url": "https://news.ycombinator.com/item?id=48547269", "by": "okanat", "date": "2026-06-15", "version": null, "stance": "recommend", "quote": "Those are all what Rust developers (who were or still are quite advanced C++ devs, btw, not people who are afraid of using raw ptrs) get freely from the Rust compiler.", "excerpt": "I'm a / used to be a C++ programmer for 10 years. I've been lucky enough to work in a company that aims to adopt Rust. I have been working on Rust projects in the embedded space that runs on real-world devices right now for 3.5 years. Slowly but surely, not going into \"rewrite every single thing now in Rust\" but one component at a time when the project justifies it. So, tell me what compiler option disables non-moder", "context": "Ex-C++ dev (10 yrs), 3.5 years on Rust embedded", "use_case": "Memory safety checking", "switched_from": "", "story": "Memory safety CVEs differ between Rust and C/C++"}, {"id": 753946608, "item_id": 47121663, "url": "https://news.ycombinator.com/item?id=47121663", "by": "gck1", "date": "2026-02-23", "version": null, "stance": "recommend", "quote": "rust compiler is a very good guardrail & feedback mechanism for AI", "excerpt": "That, and also because rust compiler is a very good guardrail & feedback mechanism for AI. I made 3 little tools that I use for myself without knowing how to write a single rust line myself.", "context": "", "use_case": "", "switched_from": "", "story": "Hetzner (European hosting provider) to increase prices by up to 38%"}]}], "caveats": [{"label": "", "summary": "", "quotes": [{"id": 801799152, "item_id": 50112447, "url": "https://news.ycombinator.com/item?id=50112447", "by": "eddifyoppor", "date": "2026-10-16", "version": null, "stance": "warn", "quote": "rustc is also awfully shoddy", "excerpt": "That \"test bed\" description fits Rust way better. Rust is in many ways also significantly more complex than C++, believe it or not. rustc is also awfully shoddy. https://github.com/rust-lang/rust/issues/164348#issuecomment-6189189325", "context": "", "use_case": "", "switched_from": "", "story": "C++26 Contracts: Introduction to Preconditions and Postconditions"}, {"id": 801793520, "item_id": 50112095, "url": "https://news.ycombinator.com/item?id=50112095", "by": "raddikal", "date": "2026-10-16", "version": null, "stance": "warn", "quote": "A bug as careless as can be.", "excerpt": "I remember a friendly member around here recently remarking that rustc is a high quality project, with lots of eyes on it and lots of effort put into it. And then this shows up. https://github.com/rust-lang/rust/issues/164348#issuecomment-6189189325 A bug as careless as can be. Relying wantonly on hashing for equality checking, without even wondering about the specific hash's collision probability.", "context": "", "use_case": "", "switched_from": "", "story": "Show HN: Proa \u2013 A Rust web framework with fast SSR and multi-target rendering"}, {"id": 797574880, "item_id": 49848430, "url": "https://news.ycombinator.com/item?id=49848430", "by": "aw1621107", "date": "2026-09-25", "version": null, "stance": "warn", "quote": "the Rust compiler fail to implement the rules of Rust the language", "excerpt": "> Isn't ten years enough to call something a feature of the language rather than a bug? I suppose it depends on who is doing the classifying? From the developer's standpoint I'd imagine intent is all that matters: a bug is something that does not match developer intent and that is (eventually) expected to be changed to match the intent, while a feature is something that does match developer intent regardless of how o", "context": "", "use_case": "", "switched_from": "", "story": "Platform-independent SIMD in Go"}, {"id": 737009920, "item_id": 46063120, "url": "https://news.ycombinator.com/item?id=46063120", "by": "jquaint", "date": "2025-11-26", "version": null, "stance": "warn", "quote": "It was annoying after buying Rust to learn that you can't play on official servers on Linux.", "excerpt": "This is cool, though I'm reluctant to give praise when they have been so weird with Linux support on their games. It was annoying after buying Rust to learn that you can't play on official servers on Linux. The game runs fine on Linux, the devs just don't allow it. https://www.pcgamer.com/games/survival-crafting/rust-developer-has-no-plans-for-linux-or-proton-support-says-games-that-support-them-are-not-serious-about", "context": "", "use_case": "", "switched_from": "", "story": "S&box is now an open source game engine"}]}], "who": [{"by": "okanat", "context": "Ex-C++ dev (10 yrs), 3.5 years on Rust embedded", "url": "https://news.ycombinator.com/item?id=48547269", "date": "2026-06-15"}], "tags": [], "use_cases": ["memory safety checking"], "compared": [{"slug": "fil-c", "name": "Fil-C", "co": 3, "switched_from": 0, "switched_to": 0}, {"slug": "mrustc", "name": "mrustc", "co": 2, "switched_from": 0, "switched_to": 0}], "makers": [{"id": 801553856, "item_id": 50097116, "url": "https://news.ycombinator.com/item?id=50097116", "by": "estebank", "date": "2026-10-14", "version": null, "stance": "neutral", "quote": "improve the user experience of rustc itself", "excerpt": "> Rust is managed by the Rust Foundation This is not quite true: the Foundation handles things like receiving and distributing some payments, helping conferences, employing people for operations (crates.io), and ownership of the trademark. But Rust the language and toolchain is managed by the people doing the work https://rust-lang.org/governance/ > It\u2019s completely possible that Rust\u2019s compiler contains a backdoor. A", "context": "", "use_case": "", "switched_from": "", "story": "Problems with the Rust Language"}, {"id": 791881632, "item_id": 49492602, "url": "https://news.ycombinator.com/item?id=49492602", "by": "camelid", "date": "2026-08-29", "version": null, "stance": "neutral", "quote": "I'm working on a project in Rustc to speed up compile times", "excerpt": "In one week in July, I sped up Rust doc-generation times by 33%. How did I discover and implement these optimizations? Find out in this post on my new blog! The improvements will land on stable in Rust 1.99. Happy to answer any questions you have. Also, if you're interested in more Rust build improvements, I'm working on a project in Rustc to speed up compile times and reduce binary sizes by automatically doing less ", "context": "", "use_case": "compiler optimizations", "switched_from": "", "story": "How I made Rustdoc 33% faster in one week"}, {"id": 771611248, "item_id": 48225703, "url": "https://news.ycombinator.com/item?id=48225703", "by": "estebank", "date": "2026-05-21", "version": null, "stance": "neutral", "quote": "In the Rust toolchain we've done the same", "excerpt": "In the Rust toolchain we've done the same. It just so happens that rustdoc already has introduced annotations for \"aliases\" so that when someone searches for push and it doesn't exist, append would show up. Having those annotations already meant that bootstrapping the feature to check the aliases during name resolution errors in rustc was almost trivial. I love it when improving one thing improves another indirectly ", "context": "", "use_case": "", "switched_from": "", "story": "Python 3.15: features that didn't make the headlines"}, {"id": 743601987, "item_id": 46475124, "url": "https://news.ycombinator.com/item?id=46475124", "by": "akshitgaur2005", "date": "2026-01-03", "version": null, "stance": "neutral", "quote": "Rust Compiler (rustc) Contributor", "excerpt": "Location: New Delhi, India Remote: Yes Willing to relocate: Yes (Global) Technologies: Rust (Compiler/Infra), C (Systems/Kernels), NixOS/Guix, RISC-V Assembly, Python (ML Infra), Burn. R\u00e9sum\u00e9/CV: https://himwant.org/resume.pdf Email: akshitgaur [at] proton [dot] me I am a CS undergrad at JNU (2027) focused on the intersection of Systems Programming and ML Infrastructure. I prefer working at the lower levels of the st", "context": "CS undergrad at JNU, class of 2027", "use_case": "", "switched_from": "", "story": "Ask HN: Who wants to be hired? (January 2026)"}], "threads": [{"url": "https://news.ycombinator.com/item?id=50211474", "title": "Today, we hacked what we'd set out to hack: the iPhone", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=50103164", "title": "C++26 Contracts: Introduction to Preconditions and Postconditions", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=50105467", "title": "Show HN: Proa \u2013 A Rust web framework with fast SSR and multi-target rendering", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=50096485", "title": "Problems with the Rust Language", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=50042362", "title": "Valen's Memory Safety: A New Kind of Borrow Checking", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=49920896", "title": "How to speed up the Rust compiler in September 2026", "mentions": 1}], "sentiment_by_month": {"2025-11": {"neutral": 2, "warn": 1}, "2025-12": {"neutral": 2}, "2026-01": {"neutral": 1, "compare": 1, "recommend": 1}, "2026-02": {"neutral": 1, "recommend": 1}, "2026-03": {"neutral": 2}, "2026-04": {"compare": 1}, "2026-05": {"neutral": 1}, "2026-06": {"recommend": 1}, "2026-07": {}, "2026-08": {"neutral": 1}, "2026-09": {"neutral": 1, "warn": 1}, "2026-10": {"neutral": 2, "warn": 2}}, "versions": [], "version_unnamed": 0, "family_ref": null, "runs_on": null, "lines": [], "quotes": [{"id": 803415312, "item_id": 50213457, "url": "https://news.ycombinator.com/item?id=50213457", "by": "gejose", "date": "2026-10-23", "version": null, "stance": "neutral", "quote": "", "excerpt": "It might not be a magic security wand, but so many critical vulnerabilities in software trace their origins to memory unsafe code and things like \"use after free\". \"~70% of the vulnerabilities Microsoft assigns a CVE each year continue to be memory safety issues\" - Microsoft [1] \"We adopted Rust for its security and are seeing a 1000x reduction in memory safety vulnerability density compared to Android\u2019s C and C++ co", "context": "", "use_case": "", "switched_from": "", "story": "Today, we hacked what we'd set out to hack: the iPhone"}, {"id": 801799152, "item_id": 50112447, "url": "https://news.ycombinator.com/item?id=50112447", "by": "eddifyoppor", "date": "2026-10-16", "version": null, "stance": "warn", "quote": "rustc is also awfully shoddy", "excerpt": "That \"test bed\" description fits Rust way better. Rust is in many ways also significantly more complex than C++, believe it or not. rustc is also awfully shoddy. https://github.com/rust-lang/rust/issues/164348#issuecomment-6189189325", "context": "", "use_case": "", "switched_from": "", "story": "C++26 Contracts: Introduction to Preconditions and Postconditions"}, {"id": 801793520, "item_id": 50112095, "url": "https://news.ycombinator.com/item?id=50112095", "by": "raddikal", "date": "2026-10-16", "version": null, "stance": "warn", "quote": "A bug as careless as can be.", "excerpt": "I remember a friendly member around here recently remarking that rustc is a high quality project, with lots of eyes on it and lots of effort put into it. And then this shows up. https://github.com/rust-lang/rust/issues/164348#issuecomment-6189189325 A bug as careless as can be. Relying wantonly on hashing for equality checking, without even wondering about the specific hash's collision probability.", "context": "", "use_case": "", "switched_from": "", "story": "Show HN: Proa \u2013 A Rust web framework with fast SSR and multi-target rendering"}, {"id": 800695041, "item_id": 50043440, "url": "https://news.ycombinator.com/item?id=50043440", "by": "verdagon", "date": "2026-10-11", "version": null, "stance": "neutral", "quote": "since rustc has CUDA now", "excerpt": "GPU compilation is definitely something I intend Valen to support. I wrote about it back in 2022, [0] and I learned a lot of lessons on how to do it (and how not to do it!) from working on the Mojo compiler. The biggest decision for Valen is what to lower to: * Rust MIR, since rustc has CUDA now, [1] (perhaps other cards soon?) * SPIR-V, like Zig does for its GPU compilation [2] * MLIR Rust MIR is looking pretty nice", "context": "", "use_case": "", "switched_from": "", "story": "Valen's Memory Safety: A New Kind of Borrow Checking"}, {"id": 798774513, "item_id": 49923407, "url": "https://news.ycombinator.com/item?id=49923407", "by": "estebank", "date": "2026-10-01", "version": null, "stance": "neutral", "quote": "then rustc will be able to produce the patches directly", "excerpt": "> Is that still true with modern linkers like `wild`? Seems like it can link Chromium in 1-2s. Wild improves things significantly, but it really depends on the kind of project. For some a third of the time can be linking. And not everyone configures their environment to use a different linker. Another thing that can easily improve performance is changing the global allocator, but I've seen teams that measured 10% per", "context": "", "use_case": "", "switched_from": "", "story": "How to speed up the Rust compiler in September 2026"}, {"id": 797574880, "item_id": 49848430, "url": "https://news.ycombinator.com/item?id=49848430", "by": "aw1621107", "date": "2026-09-25", "version": null, "stance": "warn", "quote": "the Rust compiler fail to implement the rules of Rust the language", "excerpt": "> Isn't ten years enough to call something a feature of the language rather than a bug? I suppose it depends on who is doing the classifying? From the developer's standpoint I'd imagine intent is all that matters: a bug is something that does not match developer intent and that is (eventually) expected to be changed to match the intent, while a feature is something that does match developer intent regardless of how o", "context": "", "use_case": "", "switched_from": "", "story": "Platform-independent SIMD in Go"}, {"id": 793328992, "item_id": 49583062, "url": "https://news.ycombinator.com/item?id=49583062", "by": "phire", "date": "2026-09-06", "version": null, "stance": "neutral", "quote": "", "excerpt": "> whereas a Rust object only has identity if it has a non-zero size. Rust also has the complication that function pointers are not guaranteed to have an unique identity; If multiple functions compile to the same code, the compiler is allowed de-duplicate them. The documentation [0] also warns it's also possible for the compiler to create multiple versions of the same function. And while I've absolutely seen the compi", "context": "", "use_case": "", "switched_from": "", "story": "Visualizing Rust's Vtables: How dyn Trait Works In Memory"}, {"id": 788625136, "item_id": 49289071, "url": "https://news.ycombinator.com/item?id=49289071", "by": "convolvatron", "date": "2026-08-13", "version": null, "stance": "neutral", "quote": "", "excerpt": "this one may actually be solvable, but I kinda timed out on it. okay, so I'm doing distributed systems, and my primary abstraction is a large stream that I'm using to connect components across machines. its kind of mandatory that I implement back pressure for these streams, because awful things can happen if I don't. ok, I have a large local container of records that I want to stream over a back pressured channel. no", "context": "", "use_case": "", "switched_from": "", "story": "What Garbage Collection Costs"}, {"id": 776756304, "item_id": 48547269, "url": "https://news.ycombinator.com/item?id=48547269", "by": "okanat", "date": "2026-06-15", "version": null, "stance": "recommend", "quote": "Those are all what Rust developers (who were or still are quite advanced C++ devs, btw, not people who are afraid of using raw ptrs) get freely from the Rust compiler.", "excerpt": "I'm a / used to be a C++ programmer for 10 years. I've been lucky enough to work in a company that aims to adopt Rust. I have been working on Rust projects in the embedded space that runs on real-world devices right now for 3.5 years. Slowly but surely, not going into \"rewrite every single thing now in Rust\" but one component at a time when the project justifies it. So, tell me what compiler option disables non-moder", "context": "Ex-C++ dev (10 yrs), 3.5 years on Rust embedded", "use_case": "Memory safety checking", "switched_from": "", "story": "Memory safety CVEs differ between Rust and C/C++"}, {"id": 772250560, "item_id": 48265660, "url": "https://news.ycombinator.com/item?id=48265660", "by": "virtualritz", "date": "2026-05-25", "version": null, "stance": "neutral", "quote": "", "excerpt": "I would add that Rust also has naming guidelines and sticking to them removes or at least minimizes the occurrence of another common topic of discussions on PRs/reviews. In the article, if you were to mention & follow them GetUser() in Go becomes user() in Rust[1], not get_user(). [1] https://rust-lang.github.io/api-guidelines/naming.html#getter-names-follow-rust-convention-c-getter", "context": "", "use_case": "", "switched_from": "", "story": "Migrating from Go to Rust"}, {"id": 764988385, "item_id": 47811774, "url": "https://news.ycombinator.com/item?id=47811774", "by": "DetroitThrow", "date": "2026-04-17", "version": null, "stance": "compare", "quote": "Not the same niche as Rust or Ada.", "excerpt": "I write C++ for my job everyday, and claiming Fil-C does the same thing as Rust (and that people who do rewrites in Rust are stupid) sounds braindead. I love Fil-C. It's underrated. Not the same niche as Rust or Ada.", "context": "", "use_case": "", "switched_from": "", "story": "A simplified model of Fil-C"}, {"id": 757795376, "item_id": 47362211, "url": "https://news.ycombinator.com/item?id=47362211", "by": "VorpalWay", "date": "2026-03-13", "version": null, "stance": "neutral", "quote": "", "excerpt": "> But this is all moot as long as compilers are still not conforming to the provenance model with respect to integer and pointer casts anyway and this breaks Rust too! Rust having decided something just means they life in fairy tale world, while C/C++ not having decided means they acknowledge the reality that compilers haven't fixed their optimizers. I think this is a bit of a mischaracterization. While there can of ", "context": "", "use_case": "", "switched_from": "", "story": "Emacs internals: Tagged pointers vs. C++ std:variant and LLVM (Part 3)"}, {"id": 756906560, "item_id": 47306660, "url": "https://news.ycombinator.com/item?id=47306660", "by": "aw1621107", "date": "2026-03-09", "version": null, "stance": "neutral", "quote": "rustc already tracks various compilation-related benchmarks", "excerpt": "> and they force [] libraries to support multiple modes at once, I'm not entirely sure I agree? I don't think any library except for the standard library needs to \"support multiple modes at once\"; everything else just sets its own edition and can remain blissfully unaware of whatever edition its downstream consumer(s) are using. > which is a different kind of maintenance tax than evolving C++ compilers and feature te", "context": "", "use_case": "", "switched_from": "", "story": "A Grand Vision for Rust"}, {"id": 753946608, "item_id": 47121663, "url": "https://news.ycombinator.com/item?id=47121663", "by": "gck1", "date": "2026-02-23", "version": null, "stance": "recommend", "quote": "rust compiler is a very good guardrail & feedback mechanism for AI", "excerpt": "That, and also because rust compiler is a very good guardrail & feedback mechanism for AI. I made 3 little tools that I use for myself without knowing how to write a single rust line myself.", "context": "", "use_case": "", "switched_from": "", "story": "Hetzner (European hosting provider) to increase prices by up to 38%"}, {"id": 751597392, "item_id": 46974837, "url": "https://news.ycombinator.com/item?id=46974837", "by": "gspr", "date": "2026-02-11", "version": null, "stance": "neutral", "quote": "rustc 1.93 (with `-O`) does the correct thing for size=1", "excerpt": "With `u32` as the element type, rustc 1.93 (with `-O`) does the correct thing for size=1, checks both elements separately (i.e. worse than in the article) for size=2, checks all three elements separately (i.e. not being crazy like in the article) for size=3, and starts doing SIMD at size=4. https://godbolt.org/z/5PETM5bbn", "context": "", "use_case": "", "switched_from": "", "story": "Both GCC and Clang generate strange/inefficient code"}, {"id": 747926736, "item_id": 46745421, "url": "https://news.ycombinator.com/item?id=46745421", "by": "Expurple", "date": "2026-01-24", "version": null, "stance": "recommend", "quote": "", "excerpt": "> you can still ignore the return value Only when you don't need the Ok value from the Result (in other words, only when you have Result<(), E>). You can't get any other Ok(T) out of thin air in the Err case. You must handle (exclude) the Err case in order to unwrap the T and proceed with it. > It also litters your code with branches, so not ideal for either I-cache or performance. That's simply an implementation/ABI", "context": "", "use_case": "", "switched_from": "", "story": "Banned C++ Features in Chromium"}, {"id": 747447952, "item_id": 46715497, "url": "https://news.ycombinator.com/item?id=46715497", "by": "m-hilgendorf", "date": "2026-01-21", "version": null, "stance": "compare", "quote": "the emitted code is not the same as gcc or clang when using SIMD intrinsics by default", "excerpt": "People should be aware though that the emitted code is not the same as gcc or clang when using SIMD intrinsics by default [0]. Without `-C target_feature=+<feature>` in your rustc flags the compiler may emit function calls to stubs for the intrinsic. So people should make sure they're passing the appropriate target features, especially when benchmarking. [0] https://godbolt.org/z/85nx44zcE", "context": "", "use_case": "", "switched_from": "", "story": "SIMD Programming in Pure Rust"}, {"id": 743346336, "item_id": 46459146, "url": "https://news.ycombinator.com/item?id=46459146", "by": "aw1621107", "date": "2026-01-01", "version": null, "stance": "neutral", "quote": "rustc refuses to compile this code due to multiple mutable borrows of `v`", "excerpt": "> This isn\u2019t actually unsafe unless shared across threads right? Multiple mutable borrows do not need multiple threads to cause UB. Consider the following: fn main() { let mut v = vec![0, 1, 2]; let e = &mut v[0]; v.push(3); *e = 4; } rustc refuses to compile this code due to multiple mutable borrows of `v` [0]: error[E0499]: cannot borrow `v` as mutable more than once at a time --> <source>:4:5 | 3 | let e = &mut v[", "context": "", "use_case": "", "switched_from": "", "story": "Rust\u2013: Rust without the borrow checker"}, {"id": 741205264, "item_id": 46325329, "url": "https://news.ycombinator.com/item?id=46325329", "by": "queejjd", "date": "2025-12-19", "version": null, "stance": "neutral", "quote": "", "excerpt": "Two questions: Why was the fix to this unsafe memory safety bug [0] only changes to code outside of unsafe Rust blocks?[1][2] Why does the Rustonomicon[3] say the following? > This code is 100% Safe Rust but it is also completely unsound. Changing the capacity violates the invariants of Vec (that cap reflects the allocated space in the Vec). This is not something the rest of Vec can guard against. It has to trust the", "context": "", "use_case": "", "switched_from": "", "story": "The state of the kernel Rust experiment"}, {"id": 740857952, "item_id": 46303622, "url": "https://news.ycombinator.com/item?id=46303622", "by": "om8", "date": "2025-12-17", "version": null, "stance": "neutral", "quote": "", "excerpt": "https://steveklabnik.com/writing/does-unsafe-undermine-rusts-guarantees/", "context": "", "use_case": "", "switched_from": "", "story": "Linux Kernel Rust Code Sees Its First CVE Vulnerability"}, {"id": 737009920, "item_id": 46063120, "url": "https://news.ycombinator.com/item?id=46063120", "by": "jquaint", "date": "2025-11-26", "version": null, "stance": "warn", "quote": "It was annoying after buying Rust to learn that you can't play on official servers on Linux.", "excerpt": "This is cool, though I'm reluctant to give praise when they have been so weird with Linux support on their games. It was annoying after buying Rust to learn that you can't play on official servers on Linux. The game runs fine on Linux, the devs just don't allow it. https://www.pcgamer.com/games/survival-crafting/rust-developer-has-no-plans-for-linux-or-proton-support-says-games-that-support-them-are-not-serious-about", "context": "", "use_case": "", "switched_from": "", "story": "S&box is now an open source game engine"}, {"id": 735262960, "item_id": 45953935, "url": "https://news.ycombinator.com/item?id=45953935", "by": "ViewTrick1002", "date": "2025-11-17", "version": null, "stance": "neutral", "quote": "", "excerpt": "The number is memory vulnerabilities. Not if they are exploitable. The numbers comes from this part of the article: This near-miss inevitably raises the question: \"If Rust can have memory safety vulnerabilities, then what\u2019s the point?\" The point is that the density is drastically lower. So much lower that it represents a major shift in security posture. Based on our near-miss, we can make a conservative estimate. Wit", "context": "", "use_case": "", "switched_from": "", "story": "Open-source Zig book"}, {"id": 734266912, "item_id": 45891682, "url": "https://news.ycombinator.com/item?id=45891682", "by": "bgwalter", "date": "2025-11-11", "version": null, "stance": "neutral", "quote": "", "excerpt": "Since it seems that Rust programmers are unable to provide a definition for \"memory safety\", here is what more mature and academically minded people think: https://blog.adacore.com/memory-safety-in-rust Notice that in-bounds indexing is included, same as in the definition from this submission that I quoted at you.", "context": "", "use_case": "", "switched_from": "", "story": "Memory Safety for Skeptics"}]}