Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • Yet another prove of the idea that worse is better.

    First people use unsafe poorly-designed languages for writing critical software (already worse). Then someone invents a hack making code 4x slower and consuming 2x more memory to "fix" safety issues (much worse).

    by Panzerschrek
  • Who is the author of this project? Is it a single person? A small team? A single person with LLMs?
    by Panzerschrek
  • Filip mentioned in the talk that Fil-C is his personal project.
    by ivanjermakov
  • Filip Pizło (https://www.filpizlo.com/), according to his website: Director of Programmability and Data Model at Roblox. Previously, I worked at Epic Games (Senior Director of Language Engineering) and Apple (Manager of the JavaScriptCore Team).

    He seems to be the main developer of Fil-C: https://github.com/pizlonator/fil-c although there are other contributors.

    by zdimension
  • Question for the author from someone with no expertise in the field: how does Fil-C different from 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.
    by tschambers
  • I was just thinking that we were overdue for a Fil-C post on HN.
    by LugosFergus
  • Every one of these posts is the same. There's this weird blindness to the problems and imperfections in Fil-C --- just shouting down. It reduces my confidence in Fil-C as a whole.

    Rust, for all its faults, at least engages with its critics. I've long faulted Rust's use of Result over exceptions, for example, but the maintainers at least acknowledge that other options exist and each has trade-offs. Not Pizlo and his fans.

    To be clear, I like Fil-C. It's a practical implementation of something that should have existed a long time ago. And Pizlo is, in fact, a great programmer. It just rubs me the wrong way that he can't be content with having done excellent work --- he has to claim things that his system doesn't provide (like memory safety under data races --- minor fault, but still) and claim that other systems are worse in ways they are not (e.g. with respect to Rust having unsafe blocks).

    Is genuine excellence not enough? Why must he persist in claiming a false perfection?

    by quotemstr
  • I like the inline asm sanitizer; probably could be extracted out of Fil-C.
    by ndesaulniers
  • Ha, looking through the links dang added, I came upon something I wrote back in December

    I gave (somewhat arbitrarily) the example that safe Rust is OK with a 64-bit pointer (on a modern PC for example) having the value made by the UTF-8 text "LAUGHING". That's 8 bytes, 8 bytes is 64 bits, it fits perfectly. Of course I point out, unsafe Rust, which is allowed to dereference pointers, must never dereference this LAUGHING pointer, it's not actually pointing at anything, but it is allowed to exist in safe Rust.

    Coincidentally, in like February or so this year, a new third-party Rust type "ColdString" was introduced to their reddit by somebody I've never met - I read about it and encouraged its author. ColdString is 64 bits (on modern hardware) because inside it's a pointer, and indeed if the text you wanted to store in a ColdString was "LAUGHING" you do that exactly as I described in the December post - it's just the UTF-8 encoded text, no problem. The clever trick inside ColdString is how it can know when that 64-bit pointer really is actually a pointer for longer strings - yet also allows any 0 to 8 byte UTF-8 text string to just be encoded in the ColdString itself directly.

    by tialaramex
  • How does it do that? When the 64-bit pointer is actually a pointer, does it mangle it into something that is certainly not UTF-8 (e.g. changing its top byte to 0xC0, and assuming that bits 56-63 are the same as bits 48-55, or something like that)?
    by bonzini
  • I was amazed by the presentation all the way up until 33:47, where the buggy program compiles and only errors out when the invalid access is executed. So apparently Fil-C enforces memory safety dynamically at run-time, rather than detecting these bugs at compile-time.

    A new language designed around memory safety, such as Rust, can reject large and important classes of memory-safety bugs at compile-time. Rust does not catch everything at compile-time, like bounds checks and RefCell, which are checked at run-time(, and the problems due to unsafe and C interop like explained in the presentation.)

    Still, IMO the comparison becomes a bit apples vs pears when bragging about how much more memory-safe Fil-C is than Rust. It would have been helpful to explain this important difference about run-time vs compile-time.

    Very cool and useful anyway.

    by JoelJacobson
  • The author's whole schtick is purposefully rage-baiting Rust devs, so really not that shocking that he downplays the compile-time trade-off
    by reanimus
  • I thought it was very obvious throughout the video what was happening...

    Rust has compile time checks to enforce some safety. In comparison Fil-C is a lot more memory safe, it's more comparable to being a software implementation of CHERI.

    Unfortunately it comes with downsides: runtime performance, runtime enforcement, granular safety (the safety is around allocations).

    It also comes with huge upsides: you can run C/C++ with little to no code changes. Imagine compiling nginx and the associated system libraries with Fil-C, the performance hit is probably acceptable and now the web server is memory safe.

    Rust probably provides enough memory safety (even if it is not complete safety) in most circumstances though.

    by flumpcakes
  • He claims that all syscalls are safe because they're implemented by his custom libc, but that libc then calls out to the system libc, where the system calls are unsafe. He then claims that this is unlike rust, where making a syscall is unsafe. If you stick to the rust standard library in the same way that fil-c programs stick to the fil-c standard library, then all of your rust "system calls" are safe, too.

    Someone in the audience also pointed out that a tool like this could be used to compile rust programs, not just C programs, in which case it's odd to hear Fil-C repeatedly framed as a language in opposition to rust rather than as a tool which might complement it.

    by wasmperson
  • Both Rust and Fil-C have unsafe blocks, but in Fil-C latter system, only Pizlo gets to write them. Why am I not filled with confidence?
    by quotemstr
  • also: why not use fil-c to improve cython, and the ffi.
    by cypherpunk666
  • indeed, the ideas could be used more widely.

    fil-c runs on linux.

    what if linux ran on fil-c?

    by cypherpunk666
  • 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.

    by mort96
  • > Someone in the audience also pointed out that a tool like this could be used to compile rust programs, not just C programs, in which case it's odd to hear Fil-C repeatedly framed as a language in opposition to rust rather than as a tool which might complement it.

    You can combine both approaches for sure, but that doesn't change that they are indeed separate approaches. One (Rust) intends to characterize and prevent undefined behavior at compile time, and another (Fil-C) intends to make undefined behavior impossible at runtime, as evidenced by decisions like (for example) making unsafe usage of setjmp/longjmp safe.

    You could sort of achieve "safety-in-depth" by combining both approaches, but Rust prefers to prevent all undefined behavior statically, and Fil-C prefers to focus on dynamic approaches. They have real differences, so that's probably what comes off as "oppositional"

    by LoganDark
  • Custom libc does not call to system libc.

    “Custom” and “system” aren’t 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 protections (unless you do weird stuff with /proc)

    by pizlonator
  • Rust doesn't runtime validate that your usage of syscalls is memory safe, while Fil-C does. For example you can call mmap in Fil-C and it is still guaranteed to be memory safe, while in Rust you can easily violate memory safety by calling mmap. This seems like an unambiguous improvement to me. This is as memory safe as it is possible to be on a system with a kernel that is not memory safe.

    Adding Fil-C-like runtime checks to Rust is definitely an interesting direction.

    by modeless
  • There are getting to be quite a lot of these so I'll do it CPS style:

    Memory Safe Context Switching - https://news.ycombinator.com/item?id=48727177 - June 2026 (30 comments)

    Memory Safe Inline Assembly - https://news.ycombinator.com/item?id=48606096 - June 2026 (47 comments)

    The Fil-C Optimized Calling Convention - https://news.ycombinator.com/item?id=48162876 - May 2026 (32 comments)

    A simplified model of Fil-C - https://news.ycombinator.com/item?id=47810872 - April 2026 (136 comments)

    Pizlix: Memory Safe Linux from Scratch - https://news.ycombinator.com/item?id=46260852 - Dec 2025 (30 comments)

    Linux Sandboxes and Fil-C - https://news.ycombinator.com/item?id=46259064 - Dec 2025 (156 comments)

    Ported freetype, fontconfig, harfbuzz, and graphite to Fil-C - https://news.ycombinator.com/item?id=46090009 - Nov 2025 (56 comments)

    A Note on Fil-C - https://news.ycombinator.com/item?id=45842494 - Nov 2025 (210 comments)

    Fil-C: A memory-safe C implementation - https://news.ycombinator.com/item?id=45842242 - Nov 2025 (1 comment)

    Notes by djb on using Fil-C - https://news.ycombinator.com/item?id=45788040 - Nov 2025 (246 comments)

    for more, goto https://news.ycombinator.com/item?id=45792588

    by dang