25 ms·

I've noticed that people equate "low level stuff" with unsafe, regardless of whether it's contextually justified.

steveklabnik 3mo ago
I think it's an understandable prior. Historically, "low level stuff" was near-exclusively (see my comment below about OCaml...) written in unsafe languages. Even if that wasn't always literally required, it sometimes was, and so thinking this is the case was a reasonable thing to think. It is only relatively recently that we have gained more realistic options in these spaces, and so not fully understanding the implications, or preferring the historically normal choices, is understandable.
inigyou 3mo ago
I'll play devil's advocate. I think emitting machine code intended to run is unsafe because you could emit unsafe machine code, which could run. It's the whole system that is either safe or not, not the individual components. If your system gets hacked by a buffer overflow in the end, nobody cares whether it was the linker that overflowed or the code emitted by the linker.
- AlotOfReading 3mo ago
  "Safe" has a very specific definition in Rust. It's not identical to the broader definition used in technical English. You can easily have safe rust code with behaviors any reasonable layperson would call unsafe, like crashing a plane. The original article, comment, and replies were using the word in the Rust sense from my reading, not the English meaning.
  - inigyou 3mo ago
    Then that's equivocation. Why do we want a very specific form of safety instead of wanting safety in general?
    - steveklabnik 3mo ago
      Memory safety is: 1. Foundational for other forms of safety 2. Has an objective definition, when some other forms of safety are either subjective or inter-subjective. That said, I don't understand why your parent brought this up to you, you are talking about memory safety in your original comment here, so that's what Rust's safety is about.
      - inigyou 3mo ago
        I feel that the buzz phrase "memory safety" has been defined by Rust to mean "the safety Rust gives you". Obviously memory usage can be more safe or less safe, and Rust is decidedly on the safe end of the spectrum, but it also has the gaping type system holes demonstrated in cve-rs which completely shatter any claim that safe code is safe, and there are other bugs which occur in Rust while the programmer is distracted by trying to prove their code is memory-safe.
        steveklabnik 3mo ago
        > the buzz phrase "memory safety" has been defined by Rust to mean "the safety Rust gives you". It's more that Rust's safety guarantee is memory safety. No more, no less. It's not about buzz, this term was used long before Rust existed. > it also has the gaping type system holes demonstrated in cve-rs This is not a "gaping hole". It is a compiler bug, which has never been found in the wild. > there are other bugs which occur in Rust This is true! Every language can have bugs in it, and Rust does not claim to solve all bugs.
        inigyou 3mo ago
        Does cve-rs break any type system rules? If so, why hasn't it been fixed yet?
        steveklabnik 3mo ago
        > Does cve-rs break any type system rules? Yes. > If so, why hasn't it been fixed yet? Pretty classic software engineering reasons. The part of the system that it involves was in the process of being re-written already. The re-write fixes the bug. Because it is essentially a theoretical issue, and not an actual problem in any real code, it is not a five alarm fire. Waiting for that re-write to land makes the most sense, instead of putting in a ton of work that will be thrown away. Other, more serious miscompilations get fixed faster. In fact, a version of the Rust compiler was released today to fix one, even https://blog.rust-lang.org/2026/07/16/Rust-1.97.1/ https://blog.rust-lang.org/2026/07/16/Rust-1.97.1/ This one was impacting actual users, and did not require re-writing entire subsystems to fix properly. So the engineering and product tradeoffs are different.
- steveklabnik 3mo ago
  > It's the whole system that is either safe or not, not the individual components. This is a core perspective disagreement. While this is true: > If your system gets hacked by a buffer overflow in the end, nobody cares whether it was the linker that overflowed or the code emitted by the linker. That does not mean that increasing the amount of safety in the individual components isn't helpful, because it helps minimize the above outcome, even if it will never be zero.
- nvme0n1p1 3mo ago
  That would mean no language can ever be considered safe, because any language can emit bytes to a file that will later be executed.
  - inigyou 3mo ago
    Correct. Safety is a system property, not a language property. Calling a language safe is about as sensible as calling a metal alloy unsinkable.
- BigTTYGothGF 3mo ago
  The only safe program by this measure is the one that's never ran.
- gpm 3mo ago
  Safety is a feature of a system - yes. It's also a property of what it's against. A computer could be safe against being hacked but still be dangerously easy to drop on someones toe and break it. Safety [against something] is also a feature of components - a system made up of only safe components [against a thing] is safe [against the same thing... I'm going to stop this qualification now for brevity]. A system containing unsafe components may or may not be safe but at least you know what components usage you need to look at carefully. If your linker is safe, linking code will never result in the thing it is safe against. Ever. This is a useful property even if running the linked thing is not safe because it means: 1. When things go wrong in strange ways, you have strict bounds guiding you in figuring out what went wrong. 2. You can build reliable systems that do part of the job, and only have to sandbox the other half of the job. Compiling in a CI system will (if the compiler was entirely safe) be safe. You can do it with secrets present against malicious code. Running tests will have to be sandboxed (assuming running tests isn't safe). This could for instance enable safely sharing significantly more artifacts for incremental builds in CI. Unfortunately very few compilers are really safe against anything (though I do wonder how I could break my toe on one). Rustc for instance has a giant C++ half called llvm that isn't really hardened at all. We get away with this by just not trusting the compiler when run against potentially malicious code.

I think it's an understandable prior. Historically, "low level stuff" was near-exclusively (see my comment below about OCaml...) written in unsafe languages. Even if that wasn't always literally required, it sometimes was, and so thinking this is the case was a reasonable thing to think. It is only relatively recently that we have gained more realistic options in these spaces, and so not fully understanding the implications, or preferring the historically normal choices, is understandable.

inigyou 3mo ago

I'll play devil's advocate. I think emitting machine code intended to run is unsafe because you could emit unsafe machine code, which could run. It's the whole system that is either safe or not, not the individual components. If your system gets hacked by a buffer overflow in the end, nobody cares whether it was the linker that overflowed or the code emitted by the linker.

AlotOfReading 3mo ago
"Safe" has a very specific definition in Rust. It's not identical to the broader definition used in technical English. You can easily have safe rust code with behaviors any reasonable layperson would call unsafe, like crashing a plane. The original article, comment, and replies were using the word in the Rust sense from my reading, not the English meaning.
- inigyou 3mo ago
  Then that's equivocation. Why do we want a very specific form of safety instead of wanting safety in general?
  - steveklabnik 3mo ago
    Memory safety is: 1. Foundational for other forms of safety 2. Has an objective definition, when some other forms of safety are either subjective or inter-subjective. That said, I don't understand why your parent brought this up to you, you are talking about memory safety in your original comment here, so that's what Rust's safety is about.
    - inigyou 3mo ago
      I feel that the buzz phrase "memory safety" has been defined by Rust to mean "the safety Rust gives you". Obviously memory usage can be more safe or less safe, and Rust is decidedly on the safe end of the spectrum, but it also has the gaping type system holes demonstrated in cve-rs which completely shatter any claim that safe code is safe, and there are other bugs which occur in Rust while the programmer is distracted by trying to prove their code is memory-safe.
      - steveklabnik 3mo ago
        > the buzz phrase "memory safety" has been defined by Rust to mean "the safety Rust gives you". It's more that Rust's safety guarantee is memory safety. No more, no less. It's not about buzz, this term was used long before Rust existed. > it also has the gaping type system holes demonstrated in cve-rs This is not a "gaping hole". It is a compiler bug, which has never been found in the wild. > there are other bugs which occur in Rust This is true! Every language can have bugs in it, and Rust does not claim to solve all bugs.
        inigyou 3mo ago
        Does cve-rs break any type system rules? If so, why hasn't it been fixed yet?
        steveklabnik 3mo ago
        > Does cve-rs break any type system rules? Yes. > If so, why hasn't it been fixed yet? Pretty classic software engineering reasons. The part of the system that it involves was in the process of being re-written already. The re-write fixes the bug. Because it is essentially a theoretical issue, and not an actual problem in any real code, it is not a five alarm fire. Waiting for that re-write to land makes the most sense, instead of putting in a ton of work that will be thrown away. Other, more serious miscompilations get fixed faster. In fact, a version of the Rust compiler was released today to fix one, even https://blog.rust-lang.org/2026/07/16/Rust-1.97.1/ https://blog.rust-lang.org/2026/07/16/Rust-1.97.1/ This one was impacting actual users, and did not require re-writing entire subsystems to fix properly. So the engineering and product tradeoffs are different.
steveklabnik 3mo ago
> It's the whole system that is either safe or not, not the individual components. This is a core perspective disagreement. While this is true: > If your system gets hacked by a buffer overflow in the end, nobody cares whether it was the linker that overflowed or the code emitted by the linker. That does not mean that increasing the amount of safety in the individual components isn't helpful, because it helps minimize the above outcome, even if it will never be zero.
nvme0n1p1 3mo ago
That would mean no language can ever be considered safe, because any language can emit bytes to a file that will later be executed.
- inigyou 3mo ago
  Correct. Safety is a system property, not a language property. Calling a language safe is about as sensible as calling a metal alloy unsinkable.
BigTTYGothGF 3mo ago
The only safe program by this measure is the one that's never ran.
gpm 3mo ago
Safety is a feature of a system - yes. It's also a property of what it's against. A computer could be safe against being hacked but still be dangerously easy to drop on someones toe and break it. Safety [against something] is also a feature of components - a system made up of only safe components [against a thing] is safe [against the same thing... I'm going to stop this qualification now for brevity]. A system containing unsafe components may or may not be safe but at least you know what components usage you need to look at carefully. If your linker is safe, linking code will never result in the thing it is safe against. Ever. This is a useful property even if running the linked thing is not safe because it means: 1. When things go wrong in strange ways, you have strict bounds guiding you in figuring out what went wrong. 2. You can build reliable systems that do part of the job, and only have to sandbox the other half of the job. Compiling in a CI system will (if the compiler was entirely safe) be safe. You can do it with secrets present against malicious code. Running tests will have to be sandboxed (assuming running tests isn't safe). This could for instance enable safely sharing significantly more artifacts for incremental builds in CI. Unfortunately very few compilers are really safe against anything (though I do wonder how I could break my toe on one). Rustc for instance has a giant C++ half called llvm that isn't really hardened at all. We get away with this by just not trusting the compiler when run against potentially malicious code.