Hacker News new | ask | show | jobs
by kennykartman 9 days ago
Sure, the point makes sense but if that's the sole point I think communication is quite bad. Fil-C is memory-safe only if the whole stack is compiled with Fil-C: this does not hold for Rust which does not require to recompile every dependency. Some dependencies cannot even be recompiled.

So it turns out this is not "unlike Rust", it's pretty much the same thing: if everything was built in safe rust, then it would be as safe. The communication of this point is not great at all, so much so I don't think it's purely informative.

2 comments

> So it turns out this is not "unlike Rust", it's pretty much the same thing: if everything was built in safe rust, then it would be as safe. The communication of this point is not great at all, so much so I don't think it's purely informative.

Safe Rust still basically always links against unsafe C libraries though. Fil-C will only link against libraries compiled with Fil-C which makes for a vastly stronger guarantee.

Also, plenty of code written in Rust is not safe so "if everything was built in safe rust, then it would be as safe" does not hold. There's definitely no way to write safe inline assembly in Rust.

IIUC Fil-C does not allow to freely write safe assembly language as well, right? From the inlineasm page, they say

> Parsing and analyzing the assembly. If it contains memory accesses, control flow, or anything we don't recognize, we reject it.

...But I'm no fil-c user nor expert so correct me if I'm wrong!

It would be more accurate to say Rust doesn't have the option of recompiling every dependency. If a safe Rust program links to an unsafe C module, that program is not memory safe. The "unsafe" on FFI code is not a joke.