Why I Use C When I Believe in Memory Safety

Re:Why I Use C When I Believe in Memory Safety by woodruffw on Sunday February 05, 2023 @09:08AM (#34664996)

I think that is controversial: Rust has more complex syntax than C does, but has a substantially simpler semantic model. Just a small example: given just `T*`, neither you nor your compiler knows what your global aliasing set is. The compiler has to do significantly more work to prove exclusive ownership (necessary for many optimizations), and you have no formal guarantee that your data doesn’t change underneath you.

[ Parent | on HN ]

Re:Why I Use C When I Believe in Memory Safety by medo-bear on Sunday February 05, 2023 @12:42PM (#34666842)

> Rust has more complex syntax than C does, but has a substantially simpler semantic model

i am not sure i understand, are you saying that c and rust have the same semantics ?

[ Parent | on HN ]

Re:Why I Use C When I Believe in Memory Safety by woodruffw on Sunday February 05, 2023 @01:05PM (#34667125)

They’re comparable, as evidenced by both being representable within existing compiler IRs. But no, I said that C’s semantics are significantly more complex.

[ Parent | on HN ]

Re:Why I Use C When I Believe in Memory Safety by medo-bear on Sunday February 05, 2023 @01:37PM (#34667475)

my view of c is as an abstraction over assembly. from this perspective i just cannot see that rust provides simpler semantics, unless you are trying to make c do something which you should probably use another language for, like lisp :)

[ Parent | on HN ]

Re:Why I Use C When I Believe in Memory Safety by woodruffw on Sunday February 05, 2023 @02:01PM (#34667788)

This is what I mean: C is absolutely not a naive abstraction over assembly. The C standard is clear on this: C is defined in terms of an abstract machine, which in turn doesn’t cleanly map to any particular machine architecture.

Treating C like a “high level assembler” needs a rule like the cryptographic doom principle: it will inevitably lead you astray, and “astray” for C generally means memory unsafety.

[ Parent | on HN ]

Re:Why I Use C When I Believe in Memory Safety by medo-bear on Monday February 06, 2023 @03:45AM (#34674912)

> Treating C like a “high level assembler” needs a rule like the cryptographic doom principle: it will inevitably lead you astray, and “astray” for C generally means memory unsafety

you are right. however, i think c does a better job at being a model of an abstract machine than rust. if we restrict semantics to that, and the developer accepts that they need more knowledge than just c, i think the semantics are simpler than rust's. in the same way, dont you think that rust can create a false sense of security to those not completely understanding what protections it provides? if we see programming languages as a hci problem, then i think c by default offers more freedom, and consequently more unsafety. amyway i dont want to come off as hating rust, i think it is a good language, but more importantly its community seems fantastic and i wish it success

[ Parent | on HN ]

Re:Why I Use C When I Believe in Memory Safety by woodruffw on Monday February 06, 2023 @07:10AM (#34676225)

> dont you think that rust can create a false sense of security to those not completely understanding what protections it provides?

No: the entire point of Rust's design is that you don't need to know the abstract machine semantics to write Rust safely. The compiler enforces the semantics for you, rather than pushing them onto you.

[ Parent | on HN ]

Re:Why I Use C When I Believe in Memory Safety by 0x62c1b43e on Monday February 06, 2023 @08:30AM (#34676998)

C on its own does feel like a simpler language though I think it’s true that the semantics taken literally undermine it (the generated assembly can be really surprising sometimes). I do trust a given Rust program to have a specific runtime behavior much more when optimized. It might be interesting to come up with a variant of C that has genuinely simpler semantics as well (not sure how useful I’d find it though)

[ Parent | on HN ]