4 ms·

Memory safe languages rely on someone else's software and someone else's compiler/interpreter. Rust and go are memory safe languages because their compiler are

Memory safe languages rely on someone else's software and someone else's compiler/interpreter. Rust and go are memory safe languages because their compiler are (said to be) checking all memory usage either statically or dynamically. It's still software written by someone, running on hardware designed by someone. If I write software in assembler I can just blame myself and the hardware. If I do it in C I can blame myself, the hardware, the compiler and the libraries. If I do it in Java I need to add the JRE and all the Java libraries, plus C etc. Memory safeness is just an illusion to me or a way to avoid responsibilities in case of issues.

flangola7 4y ago
And yet companies like Google have reported significant drops in memory related vulnerabilities.
- blackhaz 4y ago
  I wonder if there ever could be a C compiler doing all those checks. What is so radically different about Rust?
  - woodruffw 4y ago
    As a single example: C’s semantics prevent perfect alias analysis, meaning that a C compiler (no matter how smart) can never provide many of Rust’s basic guarantees without significantly altering the C language.
  - tialaramex 4y ago
    The lifetime analysis is only possible in Rust because Rust has lifetimes. Even if you write a toy Rust program where you didn't apparently write any lifetimes, they were implied and the implied lifetimes were checked - the language was constrained by the fact you didn't specify a lifetime and so the implied lifetime was checked, whereas in C you can't express the lifetime and so it can't be checked. The most glorious example of this is comparing C23's #embed with Rust's include_bytes! macro. These are both ways to include a file full of data into your program - which if you're a C programmer you will know was really annoying to do cross-platform before #embed In C23 the data is just some literals like 1, 86, 69, 204 that are promised to be one unsigned byte each and you do with them whatever you want. How long do they live? -shrug- in some sense forever, but, then again maybe not, it depends. But in Rust it's specifically &'static [u8; N] -- a reference to an array of N bytes which has the 'static lifetime, it lives potentially for the life of your program.
devwastaken 4y ago
Blaming you for unsafe code doesn't make code safer. Better systems over personal blame.
- nyanpasu64 4y ago
  Safe languages have restrictions like immutability, garbage collection, or "one mutator at a time" (to ensure temporal safety) outside of deliberately-awkward escape hatches (some unsafe). These tradeoffs are often workable, but some applications require no GC pauses, or placement initialization and non-allocating intrusive linked lists, which can make languages with ergonomic manual memory management a better choice for those use cases. "Safe languages are better than having to write correct code" is a thought-terminating cliche that dismisses the complex tradeoffs and limitations of safe languages.
blacklight 4y ago
> If I do it in C, I can only blame myself. Have you considered the fact that the chances that a single developer messes up memory management in an application with thousands of malloc/free/strcpy/strcat/sprintf are much higher than the chances that something breaks in a compiler that took smart people years to build just to solve the problem of memory management? Of course, if it breaks in C you can only blame yourself. But, in my opinion, it's better to blame the compiler/VM e.g. once a year, rather than blaming oneself once a week.
lapinot 4y ago
Yes, that's exactly why i have my nuclear reactor at home. I don't trust anybody else to run one. Ever heard of the concept called "abstraction" and "separation of concerns"?

flangola7 4y ago

And yet companies like Google have reported significant drops in memory related vulnerabilities.

blackhaz 4y ago
I wonder if there ever could be a C compiler doing all those checks. What is so radically different about Rust?
- woodruffw 4y ago
  As a single example: C’s semantics prevent perfect alias analysis, meaning that a C compiler (no matter how smart) can never provide many of Rust’s basic guarantees without significantly altering the C language.
- tialaramex 4y ago
  The lifetime analysis is only possible in Rust because Rust has lifetimes. Even if you write a toy Rust program where you didn't apparently write any lifetimes, they were implied and the implied lifetimes were checked - the language was constrained by the fact you didn't specify a lifetime and so the implied lifetime was checked, whereas in C you can't express the lifetime and so it can't be checked. The most glorious example of this is comparing C23's #embed with Rust's include_bytes! macro. These are both ways to include a file full of data into your program - which if you're a C programmer you will know was really annoying to do cross-platform before #embed In C23 the data is just some literals like 1, 86, 69, 204 that are promised to be one unsigned byte each and you do with them whatever you want. How long do they live? -shrug- in some sense forever, but, then again maybe not, it depends. But in Rust it's specifically &'static [u8; N] -- a reference to an array of N bytes which has the 'static lifetime, it lives potentially for the life of your program.

devwastaken 4y ago

Blaming you for unsafe code doesn't make code safer. Better systems over personal blame.

nyanpasu64 4y ago
Safe languages have restrictions like immutability, garbage collection, or "one mutator at a time" (to ensure temporal safety) outside of deliberately-awkward escape hatches (some unsafe). These tradeoffs are often workable, but some applications require no GC pauses, or placement initialization and non-allocating intrusive linked lists, which can make languages with ergonomic manual memory management a better choice for those use cases. "Safe languages are better than having to write correct code" is a thought-terminating cliche that dismisses the complex tradeoffs and limitations of safe languages.

blacklight 4y ago

> If I do it in C, I can only blame myself. Have you considered the fact that the chances that a single developer messes up memory management in an application with thousands of malloc/free/strcpy/strcat/sprintf are much higher than the chances that something breaks in a compiler that took smart people years to build just to solve the problem of memory management? Of course, if it breaks in C you can only blame yourself. But, in my opinion, it's better to blame the compiler/VM e.g. once a year, rather than blaming oneself once a week.

lapinot 4y ago

Yes, that's exactly why i have my nuclear reactor at home. I don't trust anybody else to run one. Ever heard of the concept called "abstraction" and "separation of concerns"?