| HN Mirror

To be concrete and hopefully more constructive with my criticism, he's prone to saying things like "Fil-C is safer than Rust":

https://x.com/filpizlo/status/2053351119095791995

And "Rust let’s you corrupt memory / Fil-C doesn’t.":

https://x.com/filpizlo/status/2079253367587737841

These are false claims. The following compiles and runs fine with Fil-C, happily corrupting memory in a way that a safer language like Rust would not allow:

    #include <stdint.h>
    #include <stdio.h>
    
    struct Account {
            unsigned char name[8];
            uint32_t privileged;
    };
    
    void write_name(struct Account *account, size_t index, char value)
    {
            account->name[index] = value;
    }
    
    int main(int argc, char* argv[])
    {
            struct Account acct = {
                    .name = "foobar",
                    .privileged = 42,
            };
    
            write_name(&acct, 8, 1);
    
            printf("privileged = %d\n", acct.privileged);
            return 0;
    }

His claims about Fil-C being safer than Rust seem to hinge on Fil-C's ability to make safe-er an entire application stack, compared to a hypothetical Rust application that links to C dependencies which (currently) can't be compiled with Fil-C. This is true as far as it goes, but it's a far cry from justifying a blanket statement like "Fil-C is safer than Rust".