{"slug": "fil-c", "name": "Fil-C", "category": "dev-libs", "category_name": "Libraries and frameworks", "description": "A memory-safe implementation of C and C++ using runtime checks and a garbage collector.", "recommenders": 33, "commenters": 66, "warners": 7, "score": 25.925, "rising": -2.84, "first": "2025-11-01", "latest": "2026-10-21", "why": "Commenters like Fil-C for making existing C and C++ code memory safe without a rewrite, and they note that real programs, up to a full Linux userland, already compile with it.", "why_is_quote": false, "has_verdict": true, "sentiment": {"recommend": 33, "neutral": 19, "compare": 12, "warn": 6}, "spark": [10, 4, 2, 2, 1, 2, 1, 1, 4, 2, 2, 2], "listed": true, "loved": ["Memory safety", "No rewrite needed"], "caveat": "Performance cost", "short_quote": "Any PHP install that has ~2x CPU headroom should be switched to a memory safe Fil-C build immediately.", "kind": "", "icon": false, "domain": "fil-c.org", "github_repo": null, "official_url": "https://fil-c.org/", "pricing": "open source", "aliases": ["Fil-C", "FIL-C"], "verdict": [{"text": "Commenters like Fil-C for making existing C and C++ code memory safe without a rewrite", "cites": [{"id": 795342064, "item_id": 49708879, "url": "https://news.ycombinator.com/item?id=49708879", "by": "WatchDog", "date": "2026-09-15", "version": null, "stance": "recommend", "quote": "it has stronger* memory safety guarantees than rust, none of the compatibility issues that a wholesale rewrite has", "excerpt": "Fil-C[0] can compile GNU coreutils, it has stronger* memory safety guarantees than rust, none of the compatibility issues that a wholesale rewrite has, and performance that seems to be within about a factor of two[1] compared to the normally compiled code.. [0]: https://fil-c.org/. [1]: https://bannalia.blogspot.com/2025/11/comparing-run-time-performance-of-fil-c.html * Guaranteed to crash rather than potentially gra", "context": "", "use_case": "Memory-safe C compilation", "switched_from": "", "story": "Ubuntu 26.10 completes transition to Rust-based coreutils"}, {"id": 735250592, "item_id": 45953162, "url": "https://news.ycombinator.com/item?id=45953162", "by": "cachius", "date": "2025-11-17", "version": null, "stance": "recommend", "quote": "turning it into a memory safe implementation of the C and C++ programming languages you already know and love", "excerpt": "A recent superpower was added by Fil aka the pizlonator who made C more Fil-C with FUGC, a garbage collector with minimal adjustments to existing code, turning it into a memory safe implementation of the C and C++ programming languages you already know and love. https://news.ycombinator.com/item?id=45133938 https://fil-c.org/", "context": "", "use_case": "memory-safe C/C++ compiler", "switched_from": "", "story": "Giving C a superpower: custom header file (safe_c.h)"}, {"id": 802943152, "item_id": 50183947, "url": "https://news.ycombinator.com/item?id=50183947", "by": "modeless", "date": "2026-10-21", "version": null, "stance": "recommend", "quote": "Any PHP install that has ~2x CPU headroom should be switched to a memory safe Fil-C build immediately.", "excerpt": "There is now an iron clad defense against all memory safety bugs leading to RCE that is actually practical to use in production in many cases, and people should start taking it seriously. Any PHP install that has ~2x CPU headroom should be switched to a memory safe Fil-C build immediately. More generally, anyone running network-exposed C/C++ code that is not routinely pegging the CPU should recompile with Fil-C ASAP.", "context": "", "use_case": "memory-safe builds of C/C++ code", "switched_from": "", "story": "PHP 8.2.35"}]}, {"text": ", and they note that real programs, up to a full Linux userland, already compile with it.", "cites": [{"id": 757286208, "item_id": 47330388, "url": "https://news.ycombinator.com/item?id=47330388", "by": "ppew", "date": "2026-03-10", "version": null, "stance": "recommend", "quote": "You can compile a full working linux distro with fil-c", "excerpt": "because not many people know about it? You can compile a full working linux distro with fil-c https://fil-c.org/pizlix", "context": "", "use_case": "", "switched_from": "", "story": "Fil-C is safer than Rust"}, {"id": 753201809, "item_id": 47075113, "url": "https://news.ycombinator.com/item?id=47075113", "by": "kgeist", "date": "2026-02-19", "version": null, "stance": "recommend", "quote": "userland is compiled with Fil-C", "excerpt": "Maybe this: https://fil-c.org/pizlix >Pizlix is LFS (Linux From Scratch) 12.2 with some added components, where userland is compiled with Fil-C. This means you get the most memory safe Linux-like OS currently available. The author, @pizlonator, is active on HN.", "context": "", "use_case": "memory-safe C toolchain", "switched_from": "", "story": "-fbounds-safety: Enforcing bounds safety for C"}, {"id": 785649280, "item_id": 49103080, "url": "https://news.ycombinator.com/item?id=49103080", "by": "uecker", "date": "2026-07-29", "version": null, "stance": "recommend", "quote": "It certainly works in my C programs.", "excerpt": "It certainly works in my C programs. And Fil-C demos imply that this also works for a lot of other complex real world programs, i.e. a basic Linux distribution with libreoffice on top... So yes, I would say this just works. I agree that catching this at compile-time is better, and to some degree this also works: https://godbolt.org/z/sse74vK9o Rust does not offer compile-time guarantee that an out-of-bounds access do", "context": "", "use_case": "", "switched_from": "", "story": "Zig's Incremental Compilation Internals"}]}, {"text": " The most common caveat is a cost of roughly 2x in performance", "cites": [{"id": 795342064, "item_id": 49708879, "url": "https://news.ycombinator.com/item?id=49708879", "by": "WatchDog", "date": "2026-09-15", "version": null, "stance": "recommend", "quote": "it has stronger* memory safety guarantees than rust, none of the compatibility issues that a wholesale rewrite has", "excerpt": "Fil-C[0] can compile GNU coreutils, it has stronger* memory safety guarantees than rust, none of the compatibility issues that a wholesale rewrite has, and performance that seems to be within about a factor of two[1] compared to the normally compiled code.. [0]: https://fil-c.org/. [1]: https://bannalia.blogspot.com/2025/11/comparing-run-time-performance-of-fil-c.html * Guaranteed to crash rather than potentially gra", "context": "", "use_case": "Memory-safe C compilation", "switched_from": "", "story": "Ubuntu 26.10 completes transition to Rust-based coreutils"}, {"id": 802943152, "item_id": 50183947, "url": "https://news.ycombinator.com/item?id=50183947", "by": "modeless", "date": "2026-10-21", "version": null, "stance": "recommend", "quote": "Any PHP install that has ~2x CPU headroom should be switched to a memory safe Fil-C build immediately.", "excerpt": "There is now an iron clad defense against all memory safety bugs leading to RCE that is actually practical to use in production in many cases, and people should start taking it seriously. Any PHP install that has ~2x CPU headroom should be switched to a memory safe Fil-C build immediately. More generally, anyone running network-exposed C/C++ code that is not routinely pegging the CPU should recompile with Fil-C ASAP.", "context": "", "use_case": "memory-safe builds of C/C++ code", "switched_from": "", "story": "PHP 8.2.35"}]}, {"text": ", so it suits network-exposed or infrastructure code that is not performance critical.", "cites": [{"id": 789994736, "item_id": 49374671, "url": "https://news.ycombinator.com/item?id=49374671", "by": "Tuna-Fish", "date": "2026-08-20", "version": null, "stance": "recommend", "quote": "It's an interesting option for infrastructure that's not performance critical.", "excerpt": "It's an interesting option for infrastructure that's not performance critical. I agree with Domen Ko\u017ear that I want an extern \"fil-c\" in Rust. https://domenkozar.com/2026/08/13/i-want-extern-fil-c/", "context": "", "use_case": "", "switched_from": "", "story": "Canonical Backs New Project to Translate Large C Codebases into Safe Rust"}, {"id": 802943152, "item_id": 50183947, "url": "https://news.ycombinator.com/item?id=50183947", "by": "modeless", "date": "2026-10-21", "version": null, "stance": "recommend", "quote": "Any PHP install that has ~2x CPU headroom should be switched to a memory safe Fil-C build immediately.", "excerpt": "There is now an iron clad defense against all memory safety bugs leading to RCE that is actually practical to use in production in many cases, and people should start taking it seriously. Any PHP install that has ~2x CPU headroom should be switched to a memory safe Fil-C build immediately. More generally, anyone running network-exposed C/C++ code that is not routinely pegging the CPU should recompile with Fil-C ASAP.", "context": "", "use_case": "memory-safe builds of C/C++ code", "switched_from": "", "story": "PHP 8.2.35"}, {"id": 784957056, "item_id": 49059816, "url": "https://news.ycombinator.com/item?id=49059816", "by": "DaveParkCity", "date": "2026-07-26", "version": null, "stance": "recommend", "quote": "Fil-C is an amazing technology, and we should use it", "excerpt": "I'm in the (near) memory safety absolutionist camp. Fil-C is an amazing technology, and we should use it, but we should also recognize its limitations. An as-written JIT or GC can not be compiled with Fil-C because they are inherently memory unsafe.. which means one of the biggest user CVE targets by volune, Google Chrome, not only can not be compiled by Fil-C -- it also can't consume Fil-C compiled libraries. (Chrom", "context": "", "use_case": "Memory-safe C compilation", "switched_from": "", "story": "Memory Safety Absolutists"}]}], "praise": [{"label": "Memory safety", "summary": "Commenters see it as a practical defense against memory-safety bugs that lead to remote code execution, with some calling its guarantees stronger than Rust's.", "quotes": [{"id": 802943152, "item_id": 50183947, "url": "https://news.ycombinator.com/item?id=50183947", "by": "modeless", "date": "2026-10-21", "version": null, "stance": "recommend", "quote": "Any PHP install that has ~2x CPU headroom should be switched to a memory safe Fil-C build immediately.", "excerpt": "There is now an iron clad defense against all memory safety bugs leading to RCE that is actually practical to use in production in many cases, and people should start taking it seriously. Any PHP install that has ~2x CPU headroom should be switched to a memory safe Fil-C build immediately. More generally, anyone running network-exposed C/C++ code that is not routinely pegging the CPU should recompile with Fil-C ASAP.", "context": "", "use_case": "memory-safe builds of C/C++ code", "switched_from": "", "story": "PHP 8.2.35"}, {"id": 795342064, "item_id": 49708879, "url": "https://news.ycombinator.com/item?id=49708879", "by": "WatchDog", "date": "2026-09-15", "version": null, "stance": "recommend", "quote": "it has stronger* memory safety guarantees than rust, none of the compatibility issues that a wholesale rewrite has", "excerpt": "Fil-C[0] can compile GNU coreutils, it has stronger* memory safety guarantees than rust, none of the compatibility issues that a wholesale rewrite has, and performance that seems to be within about a factor of two[1] compared to the normally compiled code.. [0]: https://fil-c.org/. [1]: https://bannalia.blogspot.com/2025/11/comparing-run-time-performance-of-fil-c.html * Guaranteed to crash rather than potentially gra", "context": "", "use_case": "Memory-safe C compilation", "switched_from": "", "story": "Ubuntu 26.10 completes transition to Rust-based coreutils"}, {"id": 796753600, "item_id": 49797100, "url": "https://news.ycombinator.com/item?id=49797100", "by": "hellcow", "date": "2026-09-22", "version": null, "stance": "recommend", "quote": "An important improvement over rust is that", "excerpt": "Behold: https://fil-c.org/ An important improvement over rust is that \"Fil-C has no unsafe statement.\"", "context": "", "use_case": "", "switched_from": "", "story": "Looking forward to Git 2.56 \u2013 and 3.0"}]}, {"label": "No rewrite needed", "summary": "Existing C code keeps decades of bug fixes while gaining memory safety, avoiding the compatibility issues of a rewrite.", "quotes": [{"id": 795342064, "item_id": 49708879, "url": "https://news.ycombinator.com/item?id=49708879", "by": "WatchDog", "date": "2026-09-15", "version": null, "stance": "recommend", "quote": "it has stronger* memory safety guarantees than rust, none of the compatibility issues that a wholesale rewrite has", "excerpt": "Fil-C[0] can compile GNU coreutils, it has stronger* memory safety guarantees than rust, none of the compatibility issues that a wholesale rewrite has, and performance that seems to be within about a factor of two[1] compared to the normally compiled code.. [0]: https://fil-c.org/. [1]: https://bannalia.blogspot.com/2025/11/comparing-run-time-performance-of-fil-c.html * Guaranteed to crash rather than potentially gra", "context": "", "use_case": "Memory-safe C compilation", "switched_from": "", "story": "Ubuntu 26.10 completes transition to Rust-based coreutils"}, {"id": 740250721, "item_id": 46265670, "url": "https://news.ycombinator.com/item?id=46265670", "by": "stefan_", "date": "2025-12-14", "version": null, "stance": "recommend", "quote": "it profits from the decades spent fixing all the logic bugs", "excerpt": "There is no \"arbitrary code execution and all kinds of nasty\" in the Fil-C version and it profits from the decades spent fixing all the logic bugs, races, environment variable mess in coreutils. Meanwhile, the Rust version of course is vulnerable to all of those: https://ubuntu.com/security/notices/USN-7867-1", "context": "", "use_case": "", "switched_from": "", "story": "Rust Coreutils 0.5.0 Release: 87.75% compatibility with GNU Coreutils"}, {"id": 735250592, "item_id": 45953162, "url": "https://news.ycombinator.com/item?id=45953162", "by": "cachius", "date": "2025-11-17", "version": null, "stance": "recommend", "quote": "turning it into a memory safe implementation of the C and C++ programming languages you already know and love", "excerpt": "A recent superpower was added by Fil aka the pizlonator who made C more Fil-C with FUGC, a garbage collector with minimal adjustments to existing code, turning it into a memory safe implementation of the C and C++ programming languages you already know and love. https://news.ycombinator.com/item?id=45133938 https://fil-c.org/", "context": "", "use_case": "memory-safe C/C++ compiler", "switched_from": "", "story": "Giving C a superpower: custom header file (safe_c.h)"}]}, {"label": "Real-world compatibility", "summary": "Commenters say it compiles real programs such as GNU coreutils and the userland of a whole Linux distribution.", "quotes": [{"id": 757286208, "item_id": 47330388, "url": "https://news.ycombinator.com/item?id=47330388", "by": "ppew", "date": "2026-03-10", "version": null, "stance": "recommend", "quote": "You can compile a full working linux distro with fil-c", "excerpt": "because not many people know about it? You can compile a full working linux distro with fil-c https://fil-c.org/pizlix", "context": "", "use_case": "", "switched_from": "", "story": "Fil-C is safer than Rust"}, {"id": 753201809, "item_id": 47075113, "url": "https://news.ycombinator.com/item?id=47075113", "by": "kgeist", "date": "2026-02-19", "version": null, "stance": "recommend", "quote": "userland is compiled with Fil-C", "excerpt": "Maybe this: https://fil-c.org/pizlix >Pizlix is LFS (Linux From Scratch) 12.2 with some added components, where userland is compiled with Fil-C. This means you get the most memory safe Linux-like OS currently available. The author, @pizlonator, is active on HN.", "context": "", "use_case": "memory-safe C toolchain", "switched_from": "", "story": "-fbounds-safety: Enforcing bounds safety for C"}, {"id": 785649280, "item_id": 49103080, "url": "https://news.ycombinator.com/item?id=49103080", "by": "uecker", "date": "2026-07-29", "version": null, "stance": "recommend", "quote": "It certainly works in my C programs.", "excerpt": "It certainly works in my C programs. And Fil-C demos imply that this also works for a lot of other complex real world programs, i.e. a basic Linux distribution with libreoffice on top... So yes, I would say this just works. I agree that catching this at compile-time is better, and to some degree this also works: https://godbolt.org/z/sse74vK9o Rust does not offer compile-time guarantee that an out-of-bounds access do", "context": "", "use_case": "", "switched_from": "", "story": "Zig's Incremental Compilation Internals"}]}, {"label": "Production practicality", "summary": "Recommended for servers, daemons and infrastructure that have spare CPU capacity.", "quotes": [{"id": 802943152, "item_id": 50183947, "url": "https://news.ycombinator.com/item?id=50183947", "by": "modeless", "date": "2026-10-21", "version": null, "stance": "recommend", "quote": "Any PHP install that has ~2x CPU headroom should be switched to a memory safe Fil-C build immediately.", "excerpt": "There is now an iron clad defense against all memory safety bugs leading to RCE that is actually practical to use in production in many cases, and people should start taking it seriously. Any PHP install that has ~2x CPU headroom should be switched to a memory safe Fil-C build immediately. More generally, anyone running network-exposed C/C++ code that is not routinely pegging the CPU should recompile with Fil-C ASAP.", "context": "", "use_case": "memory-safe builds of C/C++ code", "switched_from": "", "story": "PHP 8.2.35"}, {"id": 784957056, "item_id": 49059816, "url": "https://news.ycombinator.com/item?id=49059816", "by": "DaveParkCity", "date": "2026-07-26", "version": null, "stance": "recommend", "quote": "Fil-C is an amazing technology, and we should use it", "excerpt": "I'm in the (near) memory safety absolutionist camp. Fil-C is an amazing technology, and we should use it, but we should also recognize its limitations. An as-written JIT or GC can not be compiled with Fil-C because they are inherently memory unsafe.. which means one of the biggest user CVE targets by volune, Google Chrome, not only can not be compiled by Fil-C -- it also can't consume Fil-C compiled libraries. (Chrom", "context": "", "use_case": "Memory-safe C compilation", "switched_from": "", "story": "Memory Safety Absolutists"}, {"id": 789994736, "item_id": 49374671, "url": "https://news.ycombinator.com/item?id=49374671", "by": "Tuna-Fish", "date": "2026-08-20", "version": null, "stance": "recommend", "quote": "It's an interesting option for infrastructure that's not performance critical.", "excerpt": "It's an interesting option for infrastructure that's not performance critical. I agree with Domen Ko\u017ear that I want an extern \"fil-c\" in Rust. https://domenkozar.com/2026/08/13/i-want-extern-fil-c/", "context": "", "use_case": "", "switched_from": "", "story": "Canonical Backs New Project to Translate Large C Codebases into Safe Rust"}]}, {"label": "Easy start", "summary": "A commenter made a Bazel template that sets up a Fil-C build in a few steps.", "quotes": [{"id": 753212160, "item_id": 47075760, "url": "https://news.ycombinator.com/item?id=47075760", "by": "hsaliak", "date": "2026-02-19", "version": null, "stance": "recommend", "quote": "to make it super easy to get started with fil-c projects", "excerpt": "https://github.com/hsaliak/filc-bazel-template i created this recently to make it super easy to get started with fil-c projects. If you find it daunting to get started with the setup in the core distribution and want a 3-4 step approach to building a fil-c enabled binary, then try this.", "context": "", "use_case": "", "switched_from": "", "story": "-fbounds-safety: Enforcing bounds safety for C"}]}], "caveats": [{"label": "Performance cost", "summary": "Code runs up to about 2x slower, so commenters suggest it for code that is not performance critical.", "quotes": [{"id": 795342064, "item_id": 49708879, "url": "https://news.ycombinator.com/item?id=49708879", "by": "WatchDog", "date": "2026-09-15", "version": null, "stance": "recommend", "quote": "it has stronger* memory safety guarantees than rust, none of the compatibility issues that a wholesale rewrite has", "excerpt": "Fil-C[0] can compile GNU coreutils, it has stronger* memory safety guarantees than rust, none of the compatibility issues that a wholesale rewrite has, and performance that seems to be within about a factor of two[1] compared to the normally compiled code.. [0]: https://fil-c.org/. [1]: https://bannalia.blogspot.com/2025/11/comparing-run-time-performance-of-fil-c.html * Guaranteed to crash rather than potentially gra", "context": "", "use_case": "Memory-safe C compilation", "switched_from": "", "story": "Ubuntu 26.10 completes transition to Rust-based coreutils"}, {"id": 802943152, "item_id": 50183947, "url": "https://news.ycombinator.com/item?id=50183947", "by": "modeless", "date": "2026-10-21", "version": null, "stance": "recommend", "quote": "Any PHP install that has ~2x CPU headroom should be switched to a memory safe Fil-C build immediately.", "excerpt": "There is now an iron clad defense against all memory safety bugs leading to RCE that is actually practical to use in production in many cases, and people should start taking it seriously. Any PHP install that has ~2x CPU headroom should be switched to a memory safe Fil-C build immediately. More generally, anyone running network-exposed C/C++ code that is not routinely pegging the CPU should recompile with Fil-C ASAP.", "context": "", "use_case": "memory-safe builds of C/C++ code", "switched_from": "", "story": "PHP 8.2.35"}, {"id": 789994736, "item_id": 49374671, "url": "https://news.ycombinator.com/item?id=49374671", "by": "Tuna-Fish", "date": "2026-08-20", "version": null, "stance": "recommend", "quote": "It's an interesting option for infrastructure that's not performance critical.", "excerpt": "It's an interesting option for infrastructure that's not performance critical. I agree with Domen Ko\u017ear that I want an extern \"fil-c\" in Rust. https://domenkozar.com/2026/08/13/i-want-extern-fil-c/", "context": "", "use_case": "", "switched_from": "", "story": "Canonical Backs New Project to Translate Large C Codebases into Safe Rust"}]}, {"label": "Runtime-only checks", "summary": "Fil-C catches errors at run time rather than compile time, and it crashes instead of letting a program recover.", "quotes": [{"id": 785720560, "item_id": 49107535, "url": "https://news.ycombinator.com/item?id=49107535", "by": "uecker", "date": "2026-07-30", "version": null, "stance": "warn", "quote": "Fil-C does not ensure this.", "excerpt": "I think we agree on this. Fil-C does not ensure this. Showing the absence of run-time errors at compile-time is a hard problem, and the most realistic solution in general is via model checkers which I think would be the ideal solution, but we would need better tooling. Dependently types languages are also interesting. In the context of existing tooling and C, there is also a lot of potential in using the optimizer to", "context": "", "use_case": "memory-safe C runtime checks", "switched_from": "", "story": "Zig's Incremental Compilation Internals"}, {"id": 764987680, "item_id": 47811730, "url": "https://news.ycombinator.com/item?id=47811730", "by": "omcnoe", "date": "2026-04-17", "version": null, "stance": "warn", "quote": "Fundamentally impossible in Fil-C.", "excerpt": "https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=1f4a6572ff4691a4321b4f5167316905 Catch the panic & unwind, safe program execution continues. Fundamentally impossible in Fil-C.", "context": "", "use_case": "C memory safety compiler", "switched_from": "", "story": "A simplified model of Fil-C"}, {"id": 795342064, "item_id": 49708879, "url": "https://news.ycombinator.com/item?id=49708879", "by": "WatchDog", "date": "2026-09-15", "version": null, "stance": "recommend", "quote": "it has stronger* memory safety guarantees than rust, none of the compatibility issues that a wholesale rewrite has", "excerpt": "Fil-C[0] can compile GNU coreutils, it has stronger* memory safety guarantees than rust, none of the compatibility issues that a wholesale rewrite has, and performance that seems to be within about a factor of two[1] compared to the normally compiled code.. [0]: https://fil-c.org/. [1]: https://bannalia.blogspot.com/2025/11/comparing-run-time-performance-of-fil-c.html * Guaranteed to crash rather than potentially gra", "context": "", "use_case": "Memory-safe C compilation", "switched_from": "", "story": "Ubuntu 26.10 completes transition to Rust-based coreutils"}]}, {"label": "No JITs or GCs", "summary": "Code that implements a JIT or its own garbage collector cannot be compiled with it, which rules out programs such as Chrome.", "quotes": [{"id": 784957056, "item_id": 49059816, "url": "https://news.ycombinator.com/item?id=49059816", "by": "DaveParkCity", "date": "2026-07-26", "version": null, "stance": "recommend", "quote": "Fil-C is an amazing technology, and we should use it", "excerpt": "I'm in the (near) memory safety absolutionist camp. Fil-C is an amazing technology, and we should use it, but we should also recognize its limitations. An as-written JIT or GC can not be compiled with Fil-C because they are inherently memory unsafe.. which means one of the biggest user CVE targets by volune, Google Chrome, not only can not be compiled by Fil-C -- it also can't consume Fil-C compiled libraries. (Chrom", "context": "", "use_case": "Memory-safe C compilation", "switched_from": "", "story": "Memory Safety Absolutists"}]}, {"label": "Overstated claims", "summary": "Some commenters think the project's marketing overstates its case against Rust.", "quotes": [{"id": 785407232, "item_id": 49087952, "url": "https://news.ycombinator.com/item?id=49087952", "by": "steveklabnik", "date": "2026-07-28", "version": null, "stance": "warn", "quote": "What I do not like, primarily comes down to how the project is talked about and marketed.", "excerpt": "Okay so: in general, as a rule of thumb: anything that makes stuff have more memory safety is good. And experiments towards that end are also good. What I do not like, primarily comes down to how the project is talked about and marketed. First, because it promotes an \"us vs them\" mindset, instead of a \"we're all trying to improve memory safety\" mindset, and second, because in doing so, it also overstates its case. Th", "context": "", "use_case": "", "switched_from": "", "story": "Zig's Incremental Compilation Internals"}, {"id": 764988384, "item_id": 47811774, "url": "https://news.ycombinator.com/item?id=47811774", "by": "DetroitThrow", "date": "2026-04-17", "version": null, "stance": "recommend", "quote": "I love Fil-C. It's underrated.", "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"}]}, {"label": "Versus sanitizers", "summary": "One commenter found it underperforming existing sanitizers.", "quotes": [{"id": 784834432, "item_id": 49052152, "url": "https://news.ycombinator.com/item?id=49052152", "by": "MaulingMonkey", "date": "2026-07-25", "version": null, "stance": "warn", "quote": "Disappointing - but not unexpected - to see it underperforming existing sanitizers.", "excerpt": "I've encountered a few soundness holes in rust-lang in practice, but they've all been fixed before I managed to shoot myself in the foot with any of them: \u2022 `std::mem::uninitialized()`. It's now deprecated in favor of `MaybeUninit`. \u2022 `std::env::set_var(...)`. It's now marked `unsafe`. While I dodged the bullet, these fellows didn't: https://www.geldata.com/blog/c-stdlib-isn-t-threadsafe-and-even-safe-rust-didn-t-sav", "context": "", "use_case": "", "switched_from": "", "story": "Fil-C: Garbage In, Memory Safety Out \u2013 Filip Pizlo \u2013 SSW 2026 [video]"}]}, {"label": "Uses a GC", "summary": "It relies on a garbage collector, which one commenter pointed out as a drawback.", "quotes": [{"id": 783823168, "item_id": 48988948, "url": "https://news.ycombinator.com/item?id=48988948", "by": "pjmlp", "date": "2026-07-20", "version": null, "stance": "warn", "quote": "Fil-C, which in case they haven't been paying attention, uses a GC, go figure!", "excerpt": "I keep repeating the Modula-2/Object Pascal with curly brackets example. Zig would be a good fit in the 1990's, it is out of place in the 21st century, when we know better and better type systems became more widespread in mainstream computing. Lets not forget, Cyclone, the inspiration for Rust's typesystem, was created by AT&T, the place where UNIX and C were born, as and I quote from their site, > Cyclone thus tries", "context": "", "use_case": "", "switched_from": "", "story": "Introduce a memory safe compilation mode inspired by Fil-C"}, {"id": 735250592, "item_id": 45953162, "url": "https://news.ycombinator.com/item?id=45953162", "by": "cachius", "date": "2025-11-17", "version": null, "stance": "recommend", "quote": "turning it into a memory safe implementation of the C and C++ programming languages you already know and love", "excerpt": "A recent superpower was added by Fil aka the pizlonator who made C more Fil-C with FUGC, a garbage collector with minimal adjustments to existing code, turning it into a memory safe implementation of the C and C++ programming languages you already know and love. https://news.ycombinator.com/item?id=45133938 https://fil-c.org/", "context": "", "use_case": "memory-safe C/C++ compiler", "switched_from": "", "story": "Giving C a superpower: custom header file (safe_c.h)"}]}], "who": [], "tags": ["for existing C/C++ code", "for network-exposed services", "for Linux userland", "for non-performance-critical code"], "use_cases": ["memory-safe c compilation", "memory-safe c", "memory-safe c toolchain", "memory-safe c compiler", "memory-safe builds of c/c++ code", "memory-safe c runtime checks"], "compared": [{"slug": "llvm", "name": "LLVM", "co": 4, "switched_from": 0, "switched_to": 0}, {"slug": "rustc", "name": "rustc", "co": 3, "switched_from": 0, "switched_to": 0}, {"slug": "clang", "name": "Clang", "co": 2, "switched_from": 0, "switched_to": 0}, {"slug": "gcc", "name": "GCC", "co": 2, "switched_from": 0, "switched_to": 0}, {"slug": "addresssanitizer", "name": "AddressSanitizer", "co": 2, "switched_from": 0, "switched_to": 0}], "makers": [{"id": 804176560, "item_id": 50261035, "url": "https://news.ycombinator.com/item?id=50261035", "by": "pizlonator", "date": "2026-10-27", "version": null, "stance": "recommend", "quote": "according to our tests this turns all of the exploits into DoS", "excerpt": "This is all it takes to port PHP to Fil-C and according to our tests this turns all of the exploits into DoS https://github.com/pizlonator/fil-c/blob/deluge/projects/php.projeny", "context": "", "use_case": "memory-safe PHP port", "switched_from": "", "story": "PHP2Shell: Exploitation attempts and remediation trends"}, {"id": 799373248, "item_id": 49960828, "url": "https://news.ycombinator.com/item?id=49960828", "by": "pizlonator", "date": "2026-10-05", "version": null, "stance": "recommend", "quote": "Fil-C's GC (Fil's Unbelievable Garbage Collector) uses an alternative on-the-fly algorithm, which I call Phil's Concurrent Marking.", "excerpt": "The classic on the fly GC algorithm is DLG, hilariously published in two papers, because the first one had a bug. Here's the second paper: https://caml.inria.fr/pub/papers/doligez_gonthier-gc-popl94.pdf It's a well known algorithm. Folks who do GCs for a living know about it. The folks who work on Go are surely aware of it. I'm assuming that they do not use it for a good reason, hence my question! Fil-C's GC (Fil's U", "context": "", "use_case": "garbage collection", "switched_from": "", "story": "A 40ms Go garbage collector pause caused by swap"}, {"id": 796179312, "item_id": 49761207, "url": "https://news.ycombinator.com/item?id=49761207", "by": "charleslmunger", "date": "2026-09-18", "version": null, "stance": "neutral", "quote": "", "excerpt": "https://github.com/protocolbuffers/protobuf/commit/50f9ac3ba433e7be5869ee8ec7e7a85e6ca09a3d On a sufficiently anemic CPU doing enough fast allocation you can get measurable improvements from that kind of thing, but for a superscalar CPU and a general purpose allocator I agree you'd be hard pressed.", "context": "", "use_case": "", "switched_from": "", "story": "Size-Specialized Memory Allocation"}, {"id": 784669120, "item_id": 49041820, "url": "https://news.ycombinator.com/item?id=49041820", "by": "pizlonator", "date": "2026-07-24", "version": null, "stance": "recommend", "quote": "Hence, a Fil-C program is memory safe down to the syscalls", "excerpt": "Custom libc does not call to system libc. \u201cCustom\u201d and \u201csystem\u201d aren\u2019t the terms I use; I say user libc and you libc (because they are basically the same libc - either both are musl or both are glibc). User libc calls to the Fil-C runtime, which filters syscalls, and those filtered syscalls are made via yolo libc. Hence, a Fil-C program is memory safe down to the syscalls and syscalls cannot be used to escape the pro", "context": "", "use_case": "memory-safe C runtime", "switched_from": "", "story": "Fil-C: Garbage In, Memory Safety Out \u2013 Filip Pizlo \u2013 SSW 2026 [video]"}, {"id": 764983488, "item_id": 47811468, "url": "https://news.ycombinator.com/item?id=47811468", "by": "pizlonator", "date": "2026-04-17", "version": null, "stance": "neutral", "quote": "I am the author of Fil-C", "excerpt": "Note, I'm not the author of the OP. I am the author of Fil-C If you want to see my write-ups of how it works, start here: https://fil-c.org/how", "context": "", "use_case": "", "switched_from": "", "story": "A simplified model of Fil-C"}, {"id": 742279936, "item_id": 46392496, "url": "https://news.ycombinator.com/item?id=46392496", "by": "pizlonator", "date": "2025-12-26", "version": null, "stance": "recommend", "quote": "This is what makes almost all JS implementations, and Fil-C, memory safe.", "excerpt": "> Are you saying you somehow inhibit the optimizer from injecting a security vulnerability due to UB ala https://www.cve.org/CVERecord?id=CVE-2009-1897 ? I\u2019m kinda curious how you trick LLVM into not optimizing through UB since it\u2019s UB model is so tuned to the C/C++ standard. Yes that is inhibited. There\u2019s no trick. LLVM (and other compilers) choose to do those stupid things by policy, and the policy can be turned of", "context": "", "use_case": "memory-safe C", "switched_from": "", "story": "Memory Safety"}], "threads": [{"url": "https://news.ycombinator.com/item?id=45788040", "title": "Notes by djb on using Fil-C", "mentions": 10}, {"url": "https://news.ycombinator.com/item?id=49050058", "title": "Memory Safety Absolutists", "mentions": 7}, {"url": "https://news.ycombinator.com/item?id=49026933", "title": "Fil-C: Garbage In, Memory Safety Out \u2013 Filip Pizlo \u2013 SSW 2026 [video]", "mentions": 6}, {"url": "https://news.ycombinator.com/item?id=49085666", "title": "Zig's Incremental Compilation Internals", "mentions": 5}, {"url": "https://news.ycombinator.com/item?id=47810872", "title": "A simplified model of Fil-C", "mentions": 5}, {"url": "https://news.ycombinator.com/item?id=49289260", "title": "I want extern \"fil-C\"", "mentions": 3}], "sentiment_by_month": {"2025-11": {"recommend": 10, "neutral": 3, "warn": 1, "compare": 2}, "2025-12": {"recommend": 4, "compare": 2, "neutral": 2}, "2026-01": {"neutral": 1, "recommend": 2, "compare": 1}, "2026-02": {"recommend": 2}, "2026-03": {"recommend": 1}, "2026-04": {"compare": 2, "warn": 1, "recommend": 2, "neutral": 1}, "2026-05": {"recommend": 1}, "2026-06": {"neutral": 4, "recommend": 1}, "2026-07": {"compare": 4, "warn": 4, "neutral": 5, "recommend": 4}, "2026-08": {"neutral": 3, "recommend": 2}, "2026-09": {"compare": 1, "recommend": 2}, "2026-10": {"recommend": 2}}, "versions": [], "version_unnamed": 0, "family_ref": null, "runs_on": null, "lines": [], "quotes": [{"id": 802943152, "item_id": 50183947, "url": "https://news.ycombinator.com/item?id=50183947", "by": "modeless", "date": "2026-10-21", "version": null, "stance": "recommend", "quote": "Any PHP install that has ~2x CPU headroom should be switched to a memory safe Fil-C build immediately.", "excerpt": "There is now an iron clad defense against all memory safety bugs leading to RCE that is actually practical to use in production in many cases, and people should start taking it seriously. Any PHP install that has ~2x CPU headroom should be switched to a memory safe Fil-C build immediately. More generally, anyone running network-exposed C/C++ code that is not routinely pegging the CPU should recompile with Fil-C ASAP.", "context": "", "use_case": "memory-safe builds of C/C++ code", "switched_from": "", "story": "PHP 8.2.35"}, {"id": 800251456, "item_id": 50015716, "url": "https://news.ycombinator.com/item?id=50015716", "by": "tczMUFlmoNk", "date": "2026-10-09", "version": null, "stance": "recommend", "quote": "Fil-C is a bit of a modern marvel in that regard!", "excerpt": "I don't disagree with your general thesis, but I don't think it's right to say that defining behaviors like dereferencing a null would require a null check before every dereference. For example, Java defines the behavior of dereferencing null\u2014it throws a `NullPointerException`. My understanding is that JVMs implement this by (a) representing Java `null` references as the zero pointer, (b) mapping the zero page with w", "context": "", "use_case": "Memory-safe C compilation", "switched_from": "", "story": "Reducing undefined behavior in the C language"}, {"id": 796753600, "item_id": 49797100, "url": "https://news.ycombinator.com/item?id=49797100", "by": "hellcow", "date": "2026-09-22", "version": null, "stance": "recommend", "quote": "An important improvement over rust is that", "excerpt": "Behold: https://fil-c.org/ An important improvement over rust is that \"Fil-C has no unsafe statement.\"", "context": "", "use_case": "", "switched_from": "", "story": "Looking forward to Git 2.56 \u2013 and 3.0"}, {"id": 795342064, "item_id": 49708879, "url": "https://news.ycombinator.com/item?id=49708879", "by": "WatchDog", "date": "2026-09-15", "version": null, "stance": "recommend", "quote": "it has stronger* memory safety guarantees than rust, none of the compatibility issues that a wholesale rewrite has", "excerpt": "Fil-C[0] can compile GNU coreutils, it has stronger* memory safety guarantees than rust, none of the compatibility issues that a wholesale rewrite has, and performance that seems to be within about a factor of two[1] compared to the normally compiled code.. [0]: https://fil-c.org/. [1]: https://bannalia.blogspot.com/2025/11/comparing-run-time-performance-of-fil-c.html * Guaranteed to crash rather than potentially gra", "context": "", "use_case": "Memory-safe C compilation", "switched_from": "", "story": "Ubuntu 26.10 completes transition to Rust-based coreutils"}, {"id": 792700529, "item_id": 49543783, "url": "https://news.ycombinator.com/item?id=49543783", "by": "crote", "date": "2026-09-02", "version": null, "stance": "compare", "quote": "or you adopt a high-cost runtime checker like Fil-C", "excerpt": "Its vulnerability overview page[0] also helpfully lists which were caused by the use of C. The fact that even an extremely-high-quality codebase like Curl is still encountering things like use-after-free issues is pretty damning for the people clamoring that it is perfectly possible for skilled programmers to write safe C. If even Daniel Stenberg can't consistently write safe C code, I think we can assume that nobody", "context": "", "use_case": "", "switched_from": "", "story": "Six curl CVEs after OpenAI and Anthropic came back with zero"}, {"id": 790183632, "item_id": 49386477, "url": "https://news.ycombinator.com/item?id=49386477", "by": "sgt", "date": "2026-08-21", "version": null, "stance": "recommend", "quote": "Fil-C is the answer", "excerpt": "Or you can just stick to C, but do it in a completely memory safe way. Fil-C is the answer[0] [0] https://fil-c.org/", "context": "", "use_case": "memory-safe C", "switched_from": "", "story": "The case against a C alternative (2022)"}, {"id": 789994736, "item_id": 49374671, "url": "https://news.ycombinator.com/item?id=49374671", "by": "Tuna-Fish", "date": "2026-08-20", "version": null, "stance": "recommend", "quote": "It's an interesting option for infrastructure that's not performance critical.", "excerpt": "It's an interesting option for infrastructure that's not performance critical. I agree with Domen Ko\u017ear that I want an extern \"fil-c\" in Rust. https://domenkozar.com/2026/08/13/i-want-extern-fil-c/", "context": "", "use_case": "", "switched_from": "", "story": "Canonical Backs New Project to Translate Large C Codebases into Safe Rust"}, {"id": 788712960, "item_id": 49294560, "url": "https://news.ycombinator.com/item?id=49294560", "by": "KateLawson", "date": "2026-08-13", "version": null, "stance": "neutral", "quote": "The author of Fil-C worked on it also", "excerpt": "Any reason why you don't use clang's `-fbounds-safety`? It offers ABI compatibility and incremental adoption. The author of Fil-C worked on it also :-) https://clang.llvm.org/docs/BoundsSafety.html#overview", "context": "", "use_case": "", "switched_from": "", "story": "I want extern \"fil-C\""}, {"id": 788704097, "item_id": 49294006, "url": "https://news.ycombinator.com/item?id=49294006", "by": "pornel", "date": "2026-08-13", "version": null, "stance": "neutral", "quote": "It's not a replacement for Fil-C's role as a precise ASAN/Valgrind", "excerpt": "There is a solution that Mozilla uses in prod for legacy C codecs: https://rlbox.dev/ It's not a replacement for Fil-C's role as a precise ASAN/Valgrind, but it works great if you want to call a C library without letting it freely spray caller's memory.", "context": "", "use_case": "", "switched_from": "", "story": "I want extern \"fil-C\""}, {"id": 788699744, "item_id": 49293734, "url": "https://news.ycombinator.com/item?id=49293734", "by": "andai", "date": "2026-08-13", "version": null, "stance": "neutral", "quote": "But why should we prevent fil-C programs to be used from Rust (or C, for that matter)?", "excerpt": "Why isn't fil-C ABI compatible with C? https://fil-c.org/runtime Apparently this was done intentionally. The rationale given is that we don't want to allow non-safe C to be used in fil-C programs. Fair enough. But why should we prevent fil-C programs to be used from Rust (or C, for that matter)? I don't understand much about compilers, but I guess allowing one would also allow the other? i.e. it's not possible to mak", "context": "", "use_case": "", "switched_from": "", "story": "I want extern \"fil-C\""}, {"id": 785720560, "item_id": 49107535, "url": "https://news.ycombinator.com/item?id=49107535", "by": "uecker", "date": "2026-07-30", "version": null, "stance": "warn", "quote": "Fil-C does not ensure this.", "excerpt": "I think we agree on this. Fil-C does not ensure this. Showing the absence of run-time errors at compile-time is a hard problem, and the most realistic solution in general is via model checkers which I think would be the ideal solution, but we would need better tooling. Dependently types languages are also interesting. In the context of existing tooling and C, there is also a lot of potential in using the optimizer to", "context": "", "use_case": "memory-safe C runtime checks", "switched_from": "", "story": "Zig's Incremental Compilation Internals"}, {"id": 785649280, "item_id": 49103080, "url": "https://news.ycombinator.com/item?id=49103080", "by": "uecker", "date": "2026-07-29", "version": null, "stance": "recommend", "quote": "It certainly works in my C programs.", "excerpt": "It certainly works in my C programs. And Fil-C demos imply that this also works for a lot of other complex real world programs, i.e. a basic Linux distribution with libreoffice on top... So yes, I would say this just works. I agree that catching this at compile-time is better, and to some degree this also works: https://godbolt.org/z/sse74vK9o Rust does not offer compile-time guarantee that an out-of-bounds access do", "context": "", "use_case": "", "switched_from": "", "story": "Zig's Incremental Compilation Internals"}, {"id": 785622592, "item_id": 49101412, "url": "https://news.ycombinator.com/item?id=49101412", "by": "landr0id", "date": "2026-07-29", "version": null, "stance": "neutral", "quote": "even if Fil-C has cool technical accomplishments, I find it hard to speak positively about it", "excerpt": "Comments like these are why, even if Fil-C has cool technical accomplishments, I find it hard to speak positively about it. You unfortunately seem to forgo all nuance and push disingenuous arguments which fuel the cycle with similarly disingenuous people. I'll do you a favor though and cite a few things related to \"lobbying\" The White House put out an RFI regarding open-source security: https://bidenwhitehouse.archiv", "context": "", "use_case": "", "switched_from": "", "story": "Zig's Incremental Compilation Internals"}, {"id": 785477456, "item_id": 49092341, "url": "https://news.ycombinator.com/item?id=49092341", "by": "archargelod", "date": "2026-07-28", "version": null, "stance": "warn", "quote": "", "excerpt": "> GC languages are slower This is not necessarily true. It depends on a language, e.g. Go is slow, Nim[0] is extremely fast with conventional GC and slightly faster with ARC/ORC[1]. GC programs can be faster than manually managed ones in some cases. It's just manual memory management gives you more control of where and when free is called. And a good type system is a privelege that gives Nim more control with destruc", "context": "", "use_case": "", "switched_from": "", "story": "Zig's Incremental Compilation Internals"}, {"id": 785407232, "item_id": 49087952, "url": "https://news.ycombinator.com/item?id=49087952", "by": "steveklabnik", "date": "2026-07-28", "version": null, "stance": "warn", "quote": "What I do not like, primarily comes down to how the project is talked about and marketed.", "excerpt": "Okay so: in general, as a rule of thumb: anything that makes stuff have more memory safety is good. And experiments towards that end are also good. What I do not like, primarily comes down to how the project is talked about and marketed. First, because it promotes an \"us vs them\" mindset, instead of a \"we're all trying to improve memory safety\" mindset, and second, because in doing so, it also overstates its case. Th", "context": "", "use_case": "", "switched_from": "", "story": "Zig's Incremental Compilation Internals"}, {"id": 784957056, "item_id": 49059816, "url": "https://news.ycombinator.com/item?id=49059816", "by": "DaveParkCity", "date": "2026-07-26", "version": null, "stance": "recommend", "quote": "Fil-C is an amazing technology, and we should use it", "excerpt": "I'm in the (near) memory safety absolutionist camp. Fil-C is an amazing technology, and we should use it, but we should also recognize its limitations. An as-written JIT or GC can not be compiled with Fil-C because they are inherently memory unsafe.. which means one of the biggest user CVE targets by volune, Google Chrome, not only can not be compiled by Fil-C -- it also can't consume Fil-C compiled libraries. (Chrom", "context": "", "use_case": "Memory-safe C compilation", "switched_from": "", "story": "Memory Safety Absolutists"}, {"id": 784906208, "item_id": 49056638, "url": "https://news.ycombinator.com/item?id=49056638", "by": "brabel", "date": "2026-07-26", "version": null, "stance": "neutral", "quote": "I don't see why the full Linux kernel could not be compiled with Fil-C.", "excerpt": "Ok, I stand corrected: only the kernel userland was compiled with Fil-C. However, I don't see why the full Linux kernel could not be compiled with Fil-C. It would be nice if Fil himself could explain what limitations there are, but the documentation does not list missing C/C++ features as far as I know, it only says it's \"fanatically compatible\" which I take to mean mostly everything should work?! But to my point in ", "context": "", "use_case": "", "switched_from": "", "story": "Fil-C: Garbage In, Memory Safety Out \u2013 Filip Pizlo \u2013 SSW 2026 [video]"}, {"id": 784902720, "item_id": 49056420, "url": "https://news.ycombinator.com/item?id=49056420", "by": "blub", "date": "2026-07-26", "version": null, "stance": "neutral", "quote": "Rustafarians do seem to be worried by Fil-C and for good reason.", "excerpt": "Rustafarians do seem to be worried by Fil-C and for good reason. One of the top two issues with Rust is its cumbersome and overbearing syntax and anything which sidesteps that is automatically attractive to anyone which is worried about memory safety and doesn\u2019t like to encode every little detail about in the type system. That\u2019s the majority of programmers\u2026 think about it, that\u2019s one of the big reasons people switche", "context": "", "use_case": "memory safety for C", "switched_from": "", "story": "Memory Safety Absolutists"}, {"id": 784877569, "item_id": 49054848, "url": "https://news.ycombinator.com/item?id=49054848", "by": "safercplusplus", "date": "2026-07-25", "version": null, "stance": "recommend", "quote": "it's probably the more practical, complete and well-supported solution", "excerpt": "Well, there is another safe option for flexible pointers if you can compile as C++ [1]. In C++ you can have non-owning \"smart\" pointers with run-time-checked lifetimes [2][3]. Importantly, there is no run-time overhead to dereference them. (That is for the \"never-null\" versions, otherwise there's a null check.) Assignment has additional run-time cost, but pointer assignments are generally much less prevalent in perfo", "context": "", "use_case": "", "switched_from": "", "story": "Memory Safety Absolutists"}, {"id": 784849904, "item_id": 49053119, "url": "https://news.ycombinator.com/item?id=49053119", "by": "saghm", "date": "2026-07-25", "version": null, "stance": "compare", "quote": "", "excerpt": "> It seems like \"can switch on unsafe whenever\" vs \"has no escape hatches\" is an obvious line in the sand and a very useful distinction with real world implications. Sure, although to me, the obvious distinction is that one of them gives you more flexibility (since neither Go nor Fil-C is at risk for someone accidentally writing unsafe code). > Why in the future? It exists and can be used right now. In fact, much of ", "context": "", "use_case": "", "switched_from": "", "story": "Memory Safety Absolutists"}, {"id": 784840608, "item_id": 49052538, "url": "https://news.ycombinator.com/item?id=49052538", "by": "yjftsjthsd-h", "date": "2026-07-25", "version": null, "stance": "neutral", "quote": "Where do you see anything saying the kernel can be build with Fil-C?", "excerpt": "The video has a slide which says, > I'm running on an OS where the entire userland is compiled with Fil-C/C++ (emphasis mine) Looking up https://fil-c.org/pizlix , that says, > The kernel is compiled with Yolo-C. So that you can compile the kernel, a copy of GCC is installed in /yolo/bin/gcc. Where do you see anything saying the kernel can be build with Fil-C?", "context": "", "use_case": "", "switched_from": "", "story": "Fil-C: Garbage In, Memory Safety Out \u2013 Filip Pizlo \u2013 SSW 2026 [video]"}, {"id": 784837184, "item_id": 49052324, "url": "https://news.ycombinator.com/item?id=49052324", "by": "Animats", "date": "2026-07-25", "version": null, "stance": "compare", "quote": "it's roughly the same idea as GCC \"fat pointers\"", "excerpt": "Trying to figure out Fil-C's \"inviscaps\".[1] When you allocate space with Fil-C's \"malloc\", some additional bounds checking data precedes the space the program gets to use. Pointers are \"fat pointers\", with a pointer to the beginning of the buffer and a pointer to someplace within the buffer, allowing ordinary C pointer manipulation. There's much new verbiage around this. But it's roughly the same idea as GCC \"fat po", "context": "", "use_case": "memory-safe C bounds checking", "switched_from": "", "story": "Memory Safety Absolutists"}, {"id": 784836032, "item_id": 49052252, "url": "https://news.ycombinator.com/item?id=49052252", "by": "saghm", "date": "2026-07-25", "version": null, "stance": "compare", "quote": "Maybe Fil-C will be able to provide as large benefits to running C safely in production", "excerpt": "You can just...not use it though? It's not comparable to trying to avoid it in C/C++ because there's literally just one keyword to never use and then you're good, compared to it being possible to silently introduce in any number of ways. I put a lint in my Cargo.toml to forbid unsafe code in my projects, and now I'm guaranteed not to write unsafe code. To apply your logically consistently, you'd also have to throw ou", "context": "", "use_case": "Memory-safe C compilation", "switched_from": "", "story": "Memory Safety Absolutists"}, {"id": 784834432, "item_id": 49052152, "url": "https://news.ycombinator.com/item?id=49052152", "by": "MaulingMonkey", "date": "2026-07-25", "version": null, "stance": "warn", "quote": "Disappointing - but not unexpected - to see it underperforming existing sanitizers.", "excerpt": "I've encountered a few soundness holes in rust-lang in practice, but they've all been fixed before I managed to shoot myself in the foot with any of them: \u2022 `std::mem::uninitialized()`. It's now deprecated in favor of `MaybeUninit`. \u2022 `std::env::set_var(...)`. It's now marked `unsafe`. While I dodged the bullet, these fellows didn't: https://www.geldata.com/blog/c-stdlib-isn-t-threadsafe-and-even-safe-rust-didn-t-sav", "context": "", "use_case": "", "switched_from": "", "story": "Fil-C: Garbage In, Memory Safety Out \u2013 Filip Pizlo \u2013 SSW 2026 [video]"}, {"id": 784823680, "item_id": 49051480, "url": "https://news.ycombinator.com/item?id=49051480", "by": "himata4113", "date": "2026-07-25", "version": null, "stance": "recommend", "quote": "I want my application to be written in rust or at least use fil-c at bare minimum", "excerpt": "My biggest problem with the refusal to be memory safe is the fact that those problems end up becoming my problems when I am forced to use these applications and I have to think about how there might be a zero-click zero-day that uses an overflow in some random codec. Not as a software developer, but a regular person I want my application to be written in rust or at least use fil-c at bare minimum. Now as a software d", "context": "", "use_case": "memory-safe C", "switched_from": "", "story": "Memory Safety Absolutists"}, {"id": 784715536, "item_id": 49044721, "url": "https://news.ycombinator.com/item?id=49044721", "by": "tschambers", "date": "2026-07-24", "version": null, "stance": "compare", "quote": "how does Fil-C compare to https://security.apple.com/blog/memory-integrity-enforcement/?", "excerpt": "Question for the author from someone with no expertise in the field: how does Fil-C compare to https://security.apple.com/blog/memory-integrity-enforcement/? I'm guessing the hardware of the latter is something that Fil-C doesn't necessarily rely on.", "context": "no expertise in the field", "use_case": "", "switched_from": "", "story": "Fil-C: Garbage In, Memory Safety Out \u2013 Filip Pizlo \u2013 SSW 2026 [video]"}, {"id": 784686368, "item_id": 49042898, "url": "https://news.ycombinator.com/item?id=49042898", "by": "mort96", "date": "2026-07-24", "version": null, "stance": "neutral", "quote": "it's this general syscall function that's safe in Fil-C.", "excerpt": "In Rust, there are safe syscall wrappers, and then there's the unsafe general `syscall` function: https://docs.rs/libc/latest/libc/fn.syscall.html. If I'm understanding correctly, it's this general syscall function that's safe in Fil-C.", "context": "", "use_case": "", "switched_from": "", "story": "Fil-C: Garbage In, Memory Safety Out \u2013 Filip Pizlo \u2013 SSW 2026 [video]"}, {"id": 783823168, "item_id": 48988948, "url": "https://news.ycombinator.com/item?id=48988948", "by": "pjmlp", "date": "2026-07-20", "version": null, "stance": "warn", "quote": "Fil-C, which in case they haven't been paying attention, uses a GC, go figure!", "excerpt": "I keep repeating the Modula-2/Object Pascal with curly brackets example. Zig would be a good fit in the 1990's, it is out of place in the 21st century, when we know better and better type systems became more widespread in mainstream computing. Lets not forget, Cyclone, the inspiration for Rust's typesystem, was created by AT&T, the place where UNIX and C were born, as and I quote from their site, > Cyclone thus tries", "context": "", "use_case": "", "switched_from": "", "story": "Introduce a memory safe compilation mode inspired by Fil-C"}, {"id": 781994256, "item_id": 48874641, "url": "https://news.ycombinator.com/item?id=48874641", "by": "humam_alhusaini", "date": "2026-07-11", "version": null, "stance": "compare", "quote": "I'm not yet convinced that the issue of C's unsafety is better solved by translating it to Rust rather than using Fil-C", "excerpt": "This was featured at PLDI 26 [1]. I'm not yet convinced that the issue of C's unsafety is better solved by translating it to Rust rather than using Fil-C [2]. https://pldi26.sigplan.org/program/program-pldi-2026/ https://fil-c.org/", "context": "", "use_case": "C memory safety", "switched_from": "", "story": "Cpp2Rust: Translates C++ to safe Rust automatically"}, {"id": 779680912, "item_id": 48730057, "url": "https://news.ycombinator.com/item?id=48730057", "by": "erichocean", "date": "2026-06-30", "version": null, "stance": "neutral", "quote": "using Fil-C's garbage collector", "excerpt": "My depraved mind wants to see Jank [0] running on Fil-C, using Fil-C's garbage collector. [0] https://jank-lang.org/", "context": "", "use_case": "", "switched_from": "", "story": "Memory Safe Context Switching (longjmp, setjmp) in Fil-C"}, {"id": 779062176, "item_id": 48691386, "url": "https://news.ycombinator.com/item?id=48691386", "by": "elitepleb", "date": "2026-06-26", "version": null, "stance": "neutral", "quote": "https://github.com/pizlonator/fil-c/blob/deluge/libpas/src/libpas/fugc.c#L41", "excerpt": "https://github.com/pizlonator/fil-c/blob/deluge/libpas/src/libpas/fugc.c#L41", "context": "", "use_case": "", "switched_from": "", "story": "Gossamer: a Rust-flavoured language with real goroutines and pause-free memory"}, {"id": 778071968, "item_id": 48629498, "url": "https://news.ycombinator.com/item?id=48629498", "by": "petesergeant", "date": "2026-06-22", "version": null, "stance": "neutral", "quote": "Let's say I compile curl using Fil-C", "excerpt": "Unrelated to this specific post, but on the subject of Fil-C and Programs That Work[0]. Let's say I compile curl using Fil-C, and later an exploitable memory bug is found in curl. The implication here is that my fil-c-compiled curl will crash safely, rather than be able to be exploited? And the \"cost\" to me is that my curl executable will be slower than the standard one? 0: https://fil-c.org/programs_that_work", "context": "", "use_case": "", "switched_from": "", "story": "Memory Safe Inline Assembly"}, {"id": 778013024, "item_id": 48625814, "url": "https://news.ycombinator.com/item?id=48625814", "by": "dataflow", "date": "2026-06-21", "version": null, "stance": "recommend", "quote": "I would probably list it in [1], given how many programs depend on it.", "excerpt": "Thanks! If you don't mind a suggestion: I would probably list it in [1], given how many programs depend on it. [1] https://fil-c.org/programs_that_work", "context": "", "use_case": "", "switched_from": "", "story": "Memory Safe Inline Assembly"}, {"id": 778009328, "item_id": 48625583, "url": "https://news.ycombinator.com/item?id=48625583", "by": "anitil", "date": "2026-06-21", "version": null, "stance": "neutral", "quote": "https://fil-c.org/programs_that_work", "excerpt": "Do we have a sense for how many of the programs that work [0] are now detected as having asm violations? [0] https://fil-c.org/programs_that_work", "context": "", "use_case": "", "switched_from": "", "story": "Memory Safe Inline Assembly"}, {"id": 767956848, "item_id": 47997303, "url": "https://news.ycombinator.com/item?id=47997303", "by": "jacquesm", "date": "2026-05-03", "version": null, "stance": "recommend", "quote": "It is one of the reasons I'm interested in the FIL-C project.", "excerpt": "The problem with C - and I'm saying this as a life-long C programmer and not exactly a fan of Rust - is that C is indeed very sharp but it will cut other people just as easily even though they are far downstream of the original programmer, as well as the users of those programs. And it is extremely hard to not accidentally fall for one of the many pitfalls of C. I've got my own set of restrictions for when I'm coding", "context": "", "use_case": "Memory-safe C implementation", "switched_from": "", "story": "Embedded Rust or C Firmware? Lessons from an Industrial Microcontroller Use Case"}, {"id": 767055328, "item_id": 47940958, "url": "https://news.ycombinator.com/item?id=47940958", "by": "taylorallred", "date": "2026-04-28", "version": null, "stance": "recommend", "quote": "Pair this with Fil-C", "excerpt": "Pair this with Fil-C(https://fil-c.org/) and now you have C but as a truly bonafide scripting language.", "context": "", "use_case": "Memory-safe C", "switched_from": "", "story": "C, Just In Time!"}, {"id": 765548929, "item_id": 47846808, "url": "https://news.ycombinator.com/item?id=47846808", "by": "tnelsond4", "date": "2026-04-21", "version": null, "stance": "compare", "quote": "should I switch to Fil-C instead to debug my code?", "excerpt": "I use the bounds checker in TCC to check for memory errors in C, should I switch to Fil-C instead to debug my code? Obviously yolo-C is my target.", "context": "", "use_case": "debugging memory errors in C", "switched_from": "", "story": "How to Make a Fast Dynamic Language Interpreter"}, {"id": 764996945, "item_id": 47812309, "url": "https://news.ycombinator.com/item?id=47812309", "by": "hsaliak", "date": "2026-04-17", "version": null, "stance": "neutral", "quote": "people who may want to use these two together to make hermetic builds with it", "excerpt": "I made https://github.com/hsaliak/filc-bazel-template bazel target for people who may want to use these two together to make hermetic builds with it.", "context": "", "use_case": "", "switched_from": "", "story": "A simplified model of Fil-C"}, {"id": 764988384, "item_id": 47811774, "url": "https://news.ycombinator.com/item?id=47811774", "by": "DetroitThrow", "date": "2026-04-17", "version": null, "stance": "recommend", "quote": "I love Fil-C. It's underrated.", "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": 764987680, "item_id": 47811730, "url": "https://news.ycombinator.com/item?id=47811730", "by": "omcnoe", "date": "2026-04-17", "version": null, "stance": "warn", "quote": "Fundamentally impossible in Fil-C.", "excerpt": "https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=1f4a6572ff4691a4321b4f5167316905 Catch the panic & unwind, safe program execution continues. Fundamentally impossible in Fil-C.", "context": "", "use_case": "C memory safety compiler", "switched_from": "", "story": "A simplified model of Fil-C"}, {"id": 757286208, "item_id": 47330388, "url": "https://news.ycombinator.com/item?id=47330388", "by": "ppew", "date": "2026-03-10", "version": null, "stance": "recommend", "quote": "You can compile a full working linux distro with fil-c", "excerpt": "because not many people know about it? You can compile a full working linux distro with fil-c https://fil-c.org/pizlix", "context": "", "use_case": "", "switched_from": "", "story": "Fil-C is safer than Rust"}, {"id": 753201809, "item_id": 47075113, "url": "https://news.ycombinator.com/item?id=47075113", "by": "kgeist", "date": "2026-02-19", "version": null, "stance": "recommend", "quote": "userland is compiled with Fil-C", "excerpt": "Maybe this: https://fil-c.org/pizlix >Pizlix is LFS (Linux From Scratch) 12.2 with some added components, where userland is compiled with Fil-C. This means you get the most memory safe Linux-like OS currently available. The author, @pizlonator, is active on HN.", "context": "", "use_case": "memory-safe C toolchain", "switched_from": "", "story": "-fbounds-safety: Enforcing bounds safety for C"}, {"id": 735250592, "item_id": 45953162, "url": "https://news.ycombinator.com/item?id=45953162", "by": "cachius", "date": "2025-11-17", "version": null, "stance": "recommend", "quote": "turning it into a memory safe implementation of the C and C++ programming languages you already know and love", "excerpt": "A recent superpower was added by Fil aka the pizlonator who made C more Fil-C with FUGC, a garbage collector with minimal adjustments to existing code, turning it into a memory safe implementation of the C and C++ programming languages you already know and love. https://news.ycombinator.com/item?id=45133938 https://fil-c.org/", "context": "", "use_case": "memory-safe C/C++ compiler", "switched_from": "", "story": "Giving C a superpower: custom header file (safe_c.h)"}]}