Fil-C: Garbage In, Memory Safety Out [video] • Hacker News Board

Re: Fil-C: Garbage In, Memory Safety Out [video]

#121

Post by pjmlp » Sat, Jul 25, 2026, 6:55 AM UTC

NobodyNada wrote: post #62

dundarious wrote: post #34

Earlier quoted context omitted.

> claim that other systems are worse in ways they are not (e.g. with respect to Rust having unsafe blocks) If considering only "safety", then Fil-C is more safe than any Rust containing unsafe blocks, no? With the usual caveats about whether an abort() is safe.

Machine code is unsafe, so any memory-safe language must necessarily be built on some unsafe code somewhere . Safety is always conditional on the underlying unsafe implementation having no bugs. With Fil-C, the "unsafe blocks" live entirely within the compiler and runtime. With Rust, the unsafe foundation is the Rust compiler and standard library, as well as any unsafe code within your application or dependencies. So…

Machine code could be made safe actually, however most research topics regarding strong typed Assembly, or verified Assembly, failed to gain mindshare among commercial vendors.

One such example,

https://www.microsoft.com/en-us/research/publication/safe-to...

Re: Fil-C: Garbage In, Memory Safety Out [video]

#122

Post by uecker » Sat, Jul 25, 2026, 6:55 AM UTC

josephg wrote: post #86

uecker wrote: post #78

Earlier quoted context omitted.

A: "Rust prefers to prevent all undefined behavior statically" me: It does dynamic bounds checking. Rustaceans: But... for XYZ ... it doesn't... Sigh.

These are all true? I don’t see the problem? Rust does prefer static checks. It uses static analysis to prevent many types of bugs - including use-after-free and data races. But you’re right; rust still falls back to runtime checks when static analysis is too hard. Like dynamic bounds checking and integer overflow (in debug mode). Cell, Refcell and friends also have a (small) runtime cost. Rust prefers static analysi…

If we can all agree that my statement was true, there is no problem.

Re: Fil-C: Garbage In, Memory Safety Out [video]

#123

Post by bonzini » Sat, Jul 25, 2026, 6:57 AM UTC

pizlonator wrote: post #45

quotemstr wrote: post #8

Earlier quoted context omitted.

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?

Fil-C has no unsafe blocks

Is the runtime compiled by the Fil-C compiler, or is it a single huge unsafe block? I honestly don't know the answer.

Re: Fil-C: Garbage In, Memory Safety Out [video]

#124

Post by bonzini » Sat, Jul 25, 2026, 7:01 AM UTC

tialaramex wrote: post #61

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 LAUG…

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)?

Re: Fil-C: Garbage In, Memory Safety Out [video]

#125

Post by pjmlp » Sat, Jul 25, 2026, 7:06 AM UTC

AlotOfReading wrote: post #50

jagadaga wrote: post #32

Earlier quoted context omitted.

>I've long faulted Rust's use of Result over exceptions Why?

Not the person you're asking, but result types pessimize code more, add register pressure, use more icache for largely dead code, etc. They're arguably noisier at the source level too. That said, I've spent too much of my life chasing implicit control flow to accept exceptions. Heck, C++'s "noexcept" is a strong argument against exceptions all by itself.

C++ noexcept exists because the way C++ evolved, it is no argument against exceptions.

Exceptions came to be during the 1990's, as the C++ARM to C++98 standardisation process was taking place.

Naturally during the early days C++ compilers lacked exceptions, as CFront was introduced without them.

Then we had the C folks that were migrating to C++.

When C++ compilers finally supported exception, compilers vendors introduced the non standard switch to disable them, so that existing code could still compile with the expected behaviour.

The standard itself does not acknowledge this as allowed.

This feature was naturally misused by the anti-exception folks, same applies to how RTTI came to be.

So noexcept is a way to be able to write code to appease both camps, while surfacing what variant was chosen by the programmer.

From my point of view allowing disabling exceptions in first place was a mistake, those folks should have moved back to C, or fixed their code.

Re: Fil-C: Garbage In, Memory Safety Out [video]

#126

Post by pjmlp » Sat, Jul 25, 2026, 7:07 AM UTC

wasmperson wrote: post #71

jagadaga wrote: post #32

Earlier quoted context omitted.

>I've long faulted Rust's use of Result over exceptions Why?

The worst part about rust not having exceptions is that it actually does have exceptions, you just shouldn't use them. All the downsides and none of the benefits: https://smallcultfollowing.com/babysteps/blog/2024/05/02/unw...

Just like on Go's case, panic/recover are exceptions with bad ergonomics.

Re: Fil-C: Garbage In, Memory Safety Out [video]

#127

Post by jagadaga » Sat, Jul 25, 2026, 7:20 AM UTC

AlotOfReading wrote: post #116

anon-3988 wrote: post #114

Earlier quoted context omitted.

I don't understand why Result type is necessarily slower. Result that simply bubbles up is basically an exception, no?

You need instructions to check the result type, and a bit somewhere to store whether it's valid. Most exceptions only add extra instructions during throws/unwinding. There may or may not be an overall reduction in code size, depending on how many checks you have vs table entries.

In theory, a compiler can figure out that you don't need that in some cases.

Re: Fil-C: Garbage In, Memory Safety Out [video]

#128

Post by jagadaga » Sat, Jul 25, 2026, 7:24 AM UTC

AlotOfReading wrote: post #50

jagadaga wrote: post #32

Earlier quoted context omitted.

>I've long faulted Rust's use of Result over exceptions Why?

Not the person you're asking, but result types pessimize code more, add register pressure, use more icache for largely dead code, etc. They're arguably noisier at the source level too. That said, I've spent too much of my life chasing implicit control flow to accept exceptions. Heck, C++'s "noexcept" is a strong argument against exceptions all by itself.

    > result types pessimize code more

What does it mean?

    > They're arguably noisier at the source level too.

But they are more explicit, which means there will be fewer bugs in your code.

Re: Fil-C: Garbage In, Memory Safety Out [video]

#129

Post by JoelJacobson » Sat, Jul 25, 2026, 7:33 AM UTC

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.

Re: Fil-C: Garbage In, Memory Safety Out [video]

#130

Post by reanimus » Sat, Jul 25, 2026, 7:34 AM UTC

JoelJacobson wrote: post #129

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 n…

The author's whole schtick is purposefully rage-baiting Rust devs, so really not that shocking that he downplays the compile-time trade-off