5 ms·

>> The ultimate "the code is the documentation" is "the compiler is the language spec". Rust has a great potential to become a replacement for C and C++, but t

>> The ultimate "the code is the documentation" is "the compiler is the language spec". Rust has a great potential to become a replacement for C and C++, but the lack of a language specification is a shortcoming that needs to be addressed for it to see wider adoption, especially for safety-critical systems. If the Rust compiler does something surprising, people will ask, "Is this a bug?" and without a spec the answer becomes the language developers or the community asking, "What should the compiler do in this situation?". It makes sense because the correct behavior (whatever that is) has not been defined, but it has a feeling of "we are making this up as we go along" because there is no formalized answer defined. While this approach is fine for running your website or building a command line tool, it is not acceptable for safety-critical software. If the software breaks and people die, the "we are making this up as we go along" approach is not acceptable because it has too much risk.

lionkor 3y ago
I fully agree, and its definitely a strange feeling coming from C++ to not have a single, complete and extensive spec to read up on if all else fails. I want to like Rust, but its already a kitchen sink on par with C++ in complexity and misused quirks, not to mention macros which hide complexity just like C macros did, that the lack of a committee and spec makes it very difficult to trust that it won't get more and more features as time goes on (becoming like C++, in only the bad ways). I understand they have an RFC process, but thats not enough for a language which is now so commonplace in discussion (usually in the form of "if you did it in Rust, this problem wouldnt exist", which is often even true).
- iknowstuff 3y ago
  Rust macros don't hide anything. They're hygienic and clearly annotated when used.
  - mike_hock 3y ago
    Rust macros are a crutch to work around the language's shortcomings. It's just a better crutch than C's.
- tialaramex 3y ago
  > a single, complete and extensive spec to read up on if all else fails Did you try using the "single, complete and extensive spec" ? What for and how successful was that ? The ISO C++ standard was published in 1998, so, about 25 years ago. One of the things it says, even in the C++ 23 standard that's likely to be published later this year, is that some input files have Undefined Behaviour during parsing. But, wait a minute, Undefined Behaviour is a runtime property. Parsing isn't a runtime activity. This "complete" specification clearly was never even proofread. Which makes a kind of sense, it's an enormous sprawling document, why would anybody properly read it. But, if they actually don't, what's the point ? The fix for this - hopefully to land in C++ 26 - is P2612, named "UB? In my lexer?" because it's been so long that even "It's more likely than you think" memes https://knowyourmeme.com/memes/its-more-likely-than-you-think https://knowyourmeme.com/memes/its-more-likely-than-you-thin... are now dad jokes. But don't focus on this particular minor bug, which is not a big deal, focus on what it means about the value of the specification.
  - jcranmer 3y ago
    > But, wait a minute, Undefined Behaviour is a runtime property. Parsing isn't a runtime activity. So it turns out you're wrong here. UB can also be intentional extension points, and these aren't implementation-defined behaviors because honestly I don't want to track down 25-year-old documents to figure out what's going on here. This use of UB in the standard has diminished greatly in the past few decades (although there are still remnants of it kicking around, e.g., the lexer UB), and the extra focus on nasal demon aspects of UB from ~15 years ago really obscures this nature of UB. One annoying thing about UB is that it is actually several different concepts with the same name. In addition to the aforementioned use, it can also refer to behavior that can go haywire in ways really impossible to constrain (buffer overflow is the classical example here). Or it can refer to intentional optimization instructions (e.g., restrict and strict aliasing). Or it can refer to axioms you need to have hold or else you have no clue how to think about semantics (pointer provenance, data races). Or, incorrectly but depressingly common, lay people can use it to refer to what the specification considers implementation-defined behavior (e.g., size of data types). Working out which kind of UB people are referring to when they use the term is frustrating at best, and frequently people are using one kind of UB to justify how all kinds should be handled. (Annoyingly, some of those people are committee members.)
iknowstuff 3y ago
>a shortcoming that needs to be addressed for it to see wider adoption, especially for safety-critical systems. This seems like just a hunch of yours that does not seem to be reflected by the real world.
- thesuperbigfrog 3y ago
  >> This seems like just a hunch of yours that does not seem to be reflected by the real world. What safety-critical systems are written in Rust? Where can I buy a validated Rust toolchain for safety-critical work? Ferrocene is an effort to build a safety-critical Rust, but it is not done yet: https://ferrous-systems.com/blog/ferrocene-update/ https://ferrous-systems.com/blog/ferrocene-update/
mjw1007 3y ago
The good news is that the Rust project has recently agreed to write a specification, and has a budget to hire an editor for it. The less good news is that it's likely to take a long time before anything resembling a complete description gets written. You can follow its status at https://github.com/rust-lang/rust/issues/113527 https://github.com/rust-lang/rust/issues/113527
- thesuperbigfrog 3y ago
  >> The good news is that the Rust project has recently agreed to write a specification, and has a budget to hire an editor for it. This is awesome to hear. Following that issue . . .
duped 3y ago
I'm seeing rust adoption accelerate largely because time is spent improving the language and implementation rather than bemoaning a spec. > without a spec the answer becomes the language developers or the community asking, "What should the compiler do in this situation?". No, they ask "what does the RFC say" > If the software breaks and people die, the "we are making this up as we go along" approach is not acceptable because it has too much risk. The spec does not define the software. The software is as the software does. Having or not having a spec doesn't protect from bugs - people do. What you're taking about is covering one's ass, not specification.
- thesuperbigfrog 3y ago
  >> The spec does not define the software. The software is as the software does. Having or not having a spec doesn't protect from bugs - people do. >> What you're taking about is covering one's ass, not specification. They are related. In safety-critical software, bugs can cause people to die. Without a spec, no one will use Rust for safety critical software. It would be too risky and no company would accept that level of risk. For example if software that controls an airplane is written in Rust and an error occurs during flight, what happens? The software can't just panic and crash or the airplane might crash. The Ferrocene project (https://ferrous-systems.com/ferrocene/ https://ferrous-systems.com/ferrocene/) is working on producing a safety-critical Rust specification (https://github.com/ferrocene/specification https://github.com/ferrocene/specification) because having a language specification matters for safety-critical work.
  - duped 3y ago
    How does a spec fix bugs?
    - AnimalMuppet 3y ago
      It doesn't fix bugs (in the language/compiler). It documents exactly what the language is supposed to do, and therefore what the language user can count on. Without a spec, all you can count on is what you can experimentally determine that the language does (and even then, you can't be sure that it will do that in all situations). This actually reduces bugs in applications, because it means that the app writers now know what the language will actually do, and can write their code accordingly. Without a spec, they will too often have a cargo cult understanding of what the language does, and so their code won't do what they intend it to. If there's a spec, and the compiler/language doesn't do what the spec says, now you can definitively say that it's a bug in the language. That can still cause bugs in your app. But at least you can now definitively say that the language implementation is at fault, and demand that they fix it, and you can agree with the language authors on what "fixed" means.

lionkor 3y ago

I fully agree, and its definitely a strange feeling coming from C++ to not have a single, complete and extensive spec to read up on if all else fails. I want to like Rust, but its already a kitchen sink on par with C++ in complexity and misused quirks, not to mention macros which hide complexity just like C macros did, that the lack of a committee and spec makes it very difficult to trust that it won't get more and more features as time goes on (becoming like C++, in only the bad ways). I understand they have an RFC process, but thats not enough for a language which is now so commonplace in discussion (usually in the form of "if you did it in Rust, this problem wouldnt exist", which is often even true).

iknowstuff 3y ago
Rust macros don't hide anything. They're hygienic and clearly annotated when used.
- mike_hock 3y ago
  Rust macros are a crutch to work around the language's shortcomings. It's just a better crutch than C's.
tialaramex 3y ago
> a single, complete and extensive spec to read up on if all else fails Did you try using the "single, complete and extensive spec" ? What for and how successful was that ? The ISO C++ standard was published in 1998, so, about 25 years ago. One of the things it says, even in the C++ 23 standard that's likely to be published later this year, is that some input files have Undefined Behaviour during parsing. But, wait a minute, Undefined Behaviour is a runtime property. Parsing isn't a runtime activity. This "complete" specification clearly was never even proofread. Which makes a kind of sense, it's an enormous sprawling document, why would anybody properly read it. But, if they actually don't, what's the point ? The fix for this - hopefully to land in C++ 26 - is P2612, named "UB? In my lexer?" because it's been so long that even "It's more likely than you think" memes https://knowyourmeme.com/memes/its-more-likely-than-you-think https://knowyourmeme.com/memes/its-more-likely-than-you-thin... are now dad jokes. But don't focus on this particular minor bug, which is not a big deal, focus on what it means about the value of the specification.
- jcranmer 3y ago
  > But, wait a minute, Undefined Behaviour is a runtime property. Parsing isn't a runtime activity. So it turns out you're wrong here. UB can also be intentional extension points, and these aren't implementation-defined behaviors because honestly I don't want to track down 25-year-old documents to figure out what's going on here. This use of UB in the standard has diminished greatly in the past few decades (although there are still remnants of it kicking around, e.g., the lexer UB), and the extra focus on nasal demon aspects of UB from ~15 years ago really obscures this nature of UB. One annoying thing about UB is that it is actually several different concepts with the same name. In addition to the aforementioned use, it can also refer to behavior that can go haywire in ways really impossible to constrain (buffer overflow is the classical example here). Or it can refer to intentional optimization instructions (e.g., restrict and strict aliasing). Or it can refer to axioms you need to have hold or else you have no clue how to think about semantics (pointer provenance, data races). Or, incorrectly but depressingly common, lay people can use it to refer to what the specification considers implementation-defined behavior (e.g., size of data types). Working out which kind of UB people are referring to when they use the term is frustrating at best, and frequently people are using one kind of UB to justify how all kinds should be handled. (Annoyingly, some of those people are committee members.)

iknowstuff 3y ago

>a shortcoming that needs to be addressed for it to see wider adoption, especially for safety-critical systems. This seems like just a hunch of yours that does not seem to be reflected by the real world.

thesuperbigfrog 3y ago
>> This seems like just a hunch of yours that does not seem to be reflected by the real world. What safety-critical systems are written in Rust? Where can I buy a validated Rust toolchain for safety-critical work? Ferrocene is an effort to build a safety-critical Rust, but it is not done yet: https://ferrous-systems.com/blog/ferrocene-update/ https://ferrous-systems.com/blog/ferrocene-update/

mjw1007 3y ago

The good news is that the Rust project has recently agreed to write a specification, and has a budget to hire an editor for it. The less good news is that it's likely to take a long time before anything resembling a complete description gets written. You can follow its status at https://github.com/rust-lang/rust/issues/113527 https://github.com/rust-lang/rust/issues/113527

thesuperbigfrog 3y ago
>> The good news is that the Rust project has recently agreed to write a specification, and has a budget to hire an editor for it. This is awesome to hear. Following that issue . . .

duped 3y ago

I'm seeing rust adoption accelerate largely because time is spent improving the language and implementation rather than bemoaning a spec. > without a spec the answer becomes the language developers or the community asking, "What should the compiler do in this situation?". No, they ask "what does the RFC say" > If the software breaks and people die, the "we are making this up as we go along" approach is not acceptable because it has too much risk. The spec does not define the software. The software is as the software does. Having or not having a spec doesn't protect from bugs - people do. What you're taking about is covering one's ass, not specification.

thesuperbigfrog 3y ago
>> The spec does not define the software. The software is as the software does. Having or not having a spec doesn't protect from bugs - people do. >> What you're taking about is covering one's ass, not specification. They are related. In safety-critical software, bugs can cause people to die. Without a spec, no one will use Rust for safety critical software. It would be too risky and no company would accept that level of risk. For example if software that controls an airplane is written in Rust and an error occurs during flight, what happens? The software can't just panic and crash or the airplane might crash. The Ferrocene project (https://ferrous-systems.com/ferrocene/ https://ferrous-systems.com/ferrocene/) is working on producing a safety-critical Rust specification (https://github.com/ferrocene/specification https://github.com/ferrocene/specification) because having a language specification matters for safety-critical work.
- duped 3y ago
  How does a spec fix bugs?
  - AnimalMuppet 3y ago
    It doesn't fix bugs (in the language/compiler). It documents exactly what the language is supposed to do, and therefore what the language user can count on. Without a spec, all you can count on is what you can experimentally determine that the language does (and even then, you can't be sure that it will do that in all situations). This actually reduces bugs in applications, because it means that the app writers now know what the language will actually do, and can write their code accordingly. Without a spec, they will too often have a cargo cult understanding of what the language does, and so their code won't do what they intend it to. If there's a spec, and the compiler/language doesn't do what the spec says, now you can definitively say that it's a bug in the language. That can still cause bugs in your app. But at least you can now definitively say that the language implementation is at fault, and demand that they fix it, and you can agree with the language authors on what "fixed" means.