logoalt Hacker News

LoganDarkyesterday at 6:45 PM3 repliesview on HN

> 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"


Replies

raggiyesterday at 6:49 PM

This presentation wasn’t too bad in terms of us vs theming, but in general throughout the lifetime of the project there’s been a strong us vs them rhetoric. I think it’s working as a marketing tactic to some extent but there are better, albeit harder ways to market the thing.

show 1 reply
ueckeryesterday at 6:54 PM

Arguably the most important memory safety property, i.e. bounds checking for dynamic arrays, is also not statically checked in Rust.

show 3 replies
n42yesterday at 6:49 PM

The combination of static safety gracefully degrading to runtime safety where not provable is interesting to me

show 1 reply