onlinepersona@programming.dev
on 12 Nov 22:19
nextcollapse
I’m actually surprised there is no specification. It’s how I thought languages were written: spec first, implementation later. Do RFCs serve this purpose?
copacetic@discuss.tchncs.de
on 13 Nov 07:24
nextcollapse
Welcome to the real world. /s
snaggen@programming.dev
on 13 Nov 08:04
nextcollapse
That requires a complete picture and all possible use cases from the start. Initially when a language is new and hardly used there are much to benefit from flexibility and trying new concepts. Then as the language matures, a more formal process is needed to ensure stability. There is a reason these discussions comes now, since rust is in a very stable phase.
There might also just not be a single spec because the information is spread out over RFCs instead of being collected in a central location.
BatmanAoD@programming.dev
on 14 Nov 20:25
collapse
That’s actually not how any language has ever been written, though it’s easy to get that impression from how much the C and C++ communities emphasize their formal specifications.
But in fact, both languages were in production use for over a decade before they had a formal spec. And languages with formal specifications are actually a tiny minority of programming languages.
It’s not as if nothing is being done on GitHub we have both: rust-lang/spec which is being folded into rust-lang/reference.
I’m not sure why we don’t have an official spec, I assume that reference was originally for rustc in particular and might include some internal weirdness instead of being a proper spec. Kinda like how gcc has some internal magic that isn’t strictly to C spec.
I guess what happened was: spec for rustc -> developed rustc -> ferrocene developed from rustc spec -> “we don’t have a generic rust language spec”
BatmanAoD@programming.dev
on 14 Nov 20:22
collapse
There is indeed a caveat in the introduction to the Reference that there may be statements in it that are specific to rustc. However, the authors strive to keep statements about the implementation separate from statements about the language.
The main reason there’s not yet an “official” spec is that creating one takes enormous time and money, which are always limited resources. (Note that both C and C++ had no formal standard for over a decade after their initial release.) The Reference is “good enough” to make a formal spec not strictly necessary, and the existence of Ferrocene makes it even less necessary, since anyone who absolutely needs a spec can use Ferrocene.
Most importantly it takes a lot of effort and is essentially outdated the moment it is done unless you slow down and complicated every other process by funneling every change through the spec first.
FizzyOrange@programming.dev
on 12 Nov 23:22
nextcollapse
It’s not because we have tested this program extensively on every C++ compiler, but because the language rules of C++ say so.
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.
UnfortunateShort@lemmy.world
on 12 Nov 23:28
nextcollapse
Depends, if it’s my Rust code I’d rather get some Torvalds-Level C please
After reading LWN Kernel articles for a while now I would much rather have the Rust please. The C code base of the Linux kernel seems a total mess despite Torvalds having the final say on what is merged and what is not.
sugar_in_your_tea@sh.itjust.works
on 14 Nov 20:36
collapse
Well, he didn’t write most of it, and reviews will never be perfect.
copacetic@discuss.tchncs.de
on 13 Nov 07:20
collapse
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.
taladar@sh.itjust.works
on 13 Nov 09:28
nextcollapse
A specification is just another form of implementation that suffers from the very same problem you describe too.
copacetic@discuss.tchncs.de
on 13 Nov 10:23
collapse
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.
FizzyOrange@programming.dev
on 13 Nov 09:51
nextcollapse
you can say that without a spec as well but what does “wrong” mean then? It just means you personally disagree with its behavior.
Nope. Specs can have bugs. Here are the bugs in the C++ spec for example:
As I said, specifications are useful and desirable, but the SIL’s dogmatic “no spec = unsafe” is clearly not based in reality.
copacetic@discuss.tchncs.de
on 13 Nov 12:01
collapse
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.)
FizzyOrange@programming.dev
on 14 Nov 18:46
collapse
would not be considered bugs but maybe change requests.
That’s just playing with semantics. They are clearly bugs. They are literally called “defect reports”.
Without a spec how would you argue that a system/product is safe?
Lots of testing, including randomised testing and ideally formal verification.
Comprehensive test coverage - both code coverage (lines, branches) and functional coverage (hand written properties).
Functional safety features (ECC, redundancy, error reporting & recovery, etc.)
Engineering practices known to reduce the chance of bugs (strong static types, version control, CI & nightly tests, rigorous engineering processes - requirement tracking and so on, and yes ideally well written specifications for all the tools you are using).
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.
Software in itself cannot be safe or unsafe because without hardware it cannot do anything.
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.
copacetic@discuss.tchncs.de
on 14 Nov 19:11
collapse
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.
BatmanAoD@programming.dev
on 14 Nov 20:16
collapse
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.
BatmanAoD@programming.dev
on 14 Nov 21:44
collapse
This article somehow links to both the Reference and the Ferrocene spec, but still concludes that an official non-Ferrocene spec is necessary.
Why doesn’t the Ferrocene spec accomplish what the author wants? He states:
In other words, without a clear and authoritative specification, Rust cannot be used to achieve EAL5.
What? Why can’t the Ferrocene spec (and compiler) be used? Do Ferrocene and TÜV SÜD not count as “some group of experts”?
(Regarding the author’s opening paragraphs, the Reference does make the same distinction about drop scopes for variables versus temporaries, though I can see why he finds the Ferrocene spec clearer. But that doesn’t demonstrate that the Reference is useless as a stand-in for a specification.)
threaded - newest
I’m actually surprised there is no specification. It’s how I thought languages were written: spec first, implementation later. Do RFCs serve this purpose?
Anti Commercial-AI license
Welcome to the real world. /s
That requires a complete picture and all possible use cases from the start. Initially when a language is new and hardly used there are much to benefit from flexibility and trying new concepts. Then as the language matures, a more formal process is needed to ensure stability. There is a reason these discussions comes now, since rust is in a very stable phase.
There might also just not be a single spec because the information is spread out over RFCs instead of being collected in a central location.
That’s actually not how any language has ever been written, though it’s easy to get that impression from how much the C and C++ communities emphasize their formal specifications.
But in fact, both languages were in production use for over a decade before they had a formal spec. And languages with formal specifications are actually a tiny minority of programming languages.
It’s not as if nothing is being done on GitHub we have both: rust-lang/spec which is being folded into rust-lang/reference.
I’m not sure why we don’t have an official spec, I assume that reference was originally for rustc in particular and might include some internal weirdness instead of being a proper spec. Kinda like how gcc has some internal magic that isn’t strictly to C spec.
I guess what happened was: spec for rustc -> developed rustc -> ferrocene developed from rustc spec -> “we don’t have a generic rust language spec”
There is indeed a caveat in the introduction to the Reference that there may be statements in it that are specific to
rustc. However, the authors strive to keep statements about the implementation separate from statements about the language.The main reason there’s not yet an “official” spec is that creating one takes enormous time and money, which are always limited resources. (Note that both C and C++ had no formal standard for over a decade after their initial release.) The Reference is “good enough” to make a formal spec not strictly necessary, and the existence of Ferrocene makes it even less necessary, since anyone who absolutely needs a spec can use Ferrocene.
Most importantly it takes a lot of effort and is essentially outdated the moment it is done unless you slow down and complicated every other process by funneling every change through the spec first.
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.
Depends, if it’s my Rust code I’d rather get some Torvalds-Level C please
After reading LWN Kernel articles for a while now I would much rather have the Rust please. The C code base of the Linux kernel seems a total mess despite Torvalds having the final say on what is merged and what is not.
Well, he didn’t write most of it, and reviews will never be perfect.
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.
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.
Nope. Specs can have bugs. Here are the bugs in the C++ spec for example:
www.open-std.org/jtc1/sc22/wg21/…/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.
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.
This article somehow links to both the Reference and the Ferrocene spec, but still concludes that an official non-Ferrocene spec is necessary.
Why doesn’t the Ferrocene spec accomplish what the author wants? He states:
What? Why can’t the Ferrocene spec (and compiler) be used? Do Ferrocene and TÜV SÜD not count as “some group of experts”?
(Regarding the author’s opening paragraphs, the Reference does make the same distinction about drop scopes for variables versus temporaries, though I can see why he finds the Ferrocene spec clearer. But that doesn’t demonstrate that the Reference is useless as a stand-in for a specification.)