67
Rust needs an official specification
(tweedegolf.nl)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 12 Nov 2024
67 points (100.0% liked)
Rust
6005 readers
1 users here now
Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Wormhole
Credits
- The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)
founded 1 year ago
MODERATORS
Debatable. Saying things in a prose specification doesn't magically make them happen. Tests and reference models can though.
I also don't really agree with the SIL requirements that languages need to have rigorous specifications to be safe. Clearly it's better if they do, but would your rather fly on a rocket controlled by C code or Rust code?
IMO a specification would be really nice to have, but it main purpose is to tick a certification checkbox, which is why the only one that exists was written specifically for that purpose.
The specification does not make anything happen but it enables you to say "the implementation is wrong". Of course, you can say that without a spec as well but what does "wrong" mean then? It just means you personally disagree with its behavior. When "wrong" means "inconsistent with the spec" everybody involved can work with more clarity and fewer assumptions. Wrong assumptions can kill people flying rockets.
You can say the Rust implementation is wrong if it doesn't conform to the Reference. That is not the same as "you personally disagree with the behavior."
Rust's guarantees about the behavior of safe code are far stronger than anything C or C++ provides, with or without a formal spec.
Nope. Specs can have bugs. Here are the bugs in the C++ spec for example:
https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html
As I said, specifications are useful and desirable, but the SIL's dogmatic "no spec = unsafe" is clearly not based in reality.
In SIL world, the C++ issues would not be considered bugs but maybe change requests.
The SIL philosophy (as far as I know it from ASIL) is "unsafe unless convinced otherwise". That seems like a good idea when the lifes of humans are on the line. Without a spec how would you argue that a system/product is safe?
(Aside: Software in itself cannot be safe or unsafe because without hardware it cannot do anything. Safety must be assessed holistically including hardware and humans.)
That's just playing with semantics. They are clearly bugs. They are literally called "defect reports".
There are many aspects to safety and it's definitely a good idea to have a spec for a language, but it doesn't automatically mean safety is impossible without it.
The nice thing about abstraction is that you can talk about software without considering the hardware, more or less. If one says "this software is safe", it means it's safe assuming it's running on working hardware.
It doesn't always hold up - sometimes the abstraction leaks, e.g. for things like spectre and rowhammer. And there are sometimes performance concerns. But it's pretty good.
You definitely can do without a language spec. I heard in aerospace another approach is common: They use whatever compiler and then verify the binary. That means different tradeoffs of course.
A specification is just another form of implementation that suffers from the very same problem you describe too.
Fair enough. In practice, we resolve it recursively with a higher level specs and at some point it is just "someone wants that". In commercial software development (where SIL is used) that is a customer who pays for it or some executive.