Comment by zelphirkalt

Comment by zelphirkalt a day ago

People state these things about Rust's own implementation (or one of the other gazillion safe langs) potentially not being safe all the time, but the difference to unsafe languages is, that once any bug is fixed, everyone profits from it being fixed in the implementation of Rust. Everyone who uses the language and updates to a newer version that is, which often goes without code changes or minimal changes for a project. Now compare that with unsafe languages. Every single project needs to "fix" the same kind of safety issues over and over again. The language implementation can do almost nothing, except change the language to disallow unsafe stuff, which is not done, because people like backwards compatibility too much.

Ygg2 a day ago

> People state these things about Rust's own implementation (or one of the other gazillion safe langs) potentially not being safe all the time

Because it's technically true. The best kind of true!

Sorry, I meant to say the opposite of truth. Neither Rust nor Ada.Spark, which use LLVM as a backend, can prove via that they are correct if LLVM has bugs.

In the same way, I can't guarantee tomorrow I won't be killed by a rogue planet hitting Earth at 0.3c. So I should probably start gambling and doing coke, because we might be killed tomorrow.

> Every single project needs to "fix" the same kind of safety issues over and over again

I doubt that's the biggest problem. Each of the unsafe libraries in C/C++/Zig can be perfectly safe given invariants X and Y, respectively. What happens if you have two (or more) libraries with subtly non-compatible invariants? You get non-composable libraries. You end up with the reverse problem of the NPM world.

Reply View 2 replies

tialaramex a day ago

To be fair, although LLVM has several pretty annoying bugs which result in miscompiling Rust (and C, and any other language capable of expressing the same ideas) and it sure would be nice if they fixed them, there are also Rust bugs that live in the Rust compiler itself and aren't LLVM's responsibility.
There are some scary soundness holes in Rust's compiler that will get patched eventually but in principle you could trip them today. They're often "But why would anybody even do that?" problems, but it's technically legal Rust and the compiler doesn't reject your program or even ICE it just miscompiles your input which is not what we want.

Reply View | 1 reply
- Ygg2 a day ago
  
  > To be fair, although LLVM has several pretty annoying bugs which result in miscompiling Rust (and C, and any other language capable of expressing the same ideas) and it sure would be nice if they fixed them, there are also Rust bugs that live in the Rust compiler itself and aren't LLVM's responsibility.
  Sure. Again, I didn't say there are no bugs in Rust codebase ever, or that Rust will prevent all of errors forever.
  They are working on them, but a large chunk ~50% (45 out of 103) are either nightly-only bugs (due to nightly-only features) or LLVM bugs that are difficult to coordinate/solve.
  Some part of them will probably be helped or solved by a new trait resolver, Polonius. Granted, this still won't resolve all issues. Or even all trait related issues.
  > There are some scary soundness holes in Rust's compiler that will get patched eventually but in principle you could trip them today.
  In principle, yes. In principle you should cower in a corner, because there are many scary things in the world. From microbes, to insects, to malevolent proteins, to meteors, to gamma rays, to strangelets, to rogue black holes, to gravity entering a new stable state.
  In practice, you don't. Because in practice we empirically adjust our expectations to the phenomena that occur, or have occurred. So a war is very likely, but being vaporized by a stray cosmic ray is not very likely.
  And most of those UB require either strange code or a weird combination of hardware, compilers, or flags. It's probably why most people don't encounter UB in everyday Rust.
  
  Reply View | 0 replies