10 ms·

Do we need a “Rust Standard”?

40 points by georgehill 4y ago

suprjami 4y ago
With GCC adding Rust support there is no longer one "official" compiler. In many people's eyes GCC will be considered "the" Rust compiler. If Rust wants to supplant C in embedded, a specification is required. I'm honestly surprised Linux is accepting unspecified code into the kernel with the addition of Rust.
- Macha 4y ago
  Linux's C code doesn't stick to the C standard either, it uses plenty of GCC extensions, and it's not clear Clang would have implemented all of them if it wasn't for their use in the Linux kernel. So a language specification is not that high on the Linux priorities list.
- tialaramex 4y ago
  Linux doesn't even obey ISO C's Memory Model. Linux was multi-processor many years before ISO C11 documents a Memory Model (the same one as C++ 11) and so it had many years to decide how this stuff should work in practice on actual multi-processor hardware. https://lwn.net/Articles/718628/ https://lwn.net/Articles/718628/ The Linux model and the C++ 11 (as subsequently modified) model are similar in the sense that they respect how the CPU actually works, necessarily in the case of Linux and for practical low level C or C++, but in details they differ, sometimes for good reason and sometimes just because Linux was here first.
  - simplotek 4y ago
    > Linux doesn't even obey ISO C's Memory Model. Red herring. If I recall correctly, Linus publicly stated a number of times that C's memory model is relevant for userspace code but OS development has its own requirements. Amusingly enough, I recall that this discussion was about Rust, and the way that Rust proponents advocated pushing Rust's memory model onto Linux.
- madmoose 4y ago
  > With GCC adding Rust support there is no longer one "official" compiler. No, there's will still only be one official compiler – the one written and provided by The Rust Project. > If Rust wants to supplant C in embedded, a specification is required. You're getting your history backwards. C did not become successful because of its specification, it got a specification because it was successful. Similarly, if Rust becomes successful enough, it will probably get a specification. But the popularity will drive the work on a specification, not the other way around.
  - simplotek 4y ago
    > C did not become successful because of its specification, it got a specification because it was successful. I disagree. The need for a standard specification of what the C programming language is sprung from the need to ensure that multiple independent compiler implementations were actually compatible and supported the same sets of features. If a nonstandard C ecosystem had to endure the pain of either targeting products from specific vendors or waste time maintaining a caniuse database of C features, the amount of wasted effort to just keep code building would make things too challenging and troublesome to maintain. Consequently, we would see gradual fragmentation both within the C-like ecosystem and in other potential C-like successors that ink offered minor changes.
tialaramex 4y ago
As well as obeying Betteridge's Law, Mara's article hits a few frequent mistakes that crop up in Rust discussions: e.g. how Editions are different (I would say better) than versions of a standard language like C++. One thing I think is worth more reflection is: Are there specific things such a Specification must cover, or is it enough, as it seems C and C++ felt, to just specify some of the language and leave the rest unacknowledged ? For example, ANSI and ISO C significantly pre-date the memory model we're all now comfortable C implements. They don't offer a different memory model, the specification just never mentions what's going on at all in this respect. If you wrote concurrent software in C in, say, 1996 (which I did) then eh, it does whatever it is that it happens to do. The ISO standard document has no view. Right now, Rust "pretty blatantly just inherits the memory model for atomics from C++20. This is not due to this model being particularly excellent or easy to understand. Indeed, this model is quite complex and known to have several flaws. Rather, it is a pragmatic concession" (quoting the Nomicon). Is that good enough? If Aria's Strict Provenance experiment goes well, how much of that should be specified? As much as possible? As little as possible?
rowanG077 4y ago
Isn't the rustc compiler the runnable spec? I don't particularly see the need to build a parallel spec just for people who don't want to read the code.
- conradludgate 4y ago
  I think this logic is flawed. If we find a bug in the compiler, is that now a guaranteed behaviour as being the implicit spec? I think a spec is different in a way that allows it to document expected behaviour vs implemented behaviour
  - rowanG077 4y ago
    A traditional spec doesn't fix that issue it has "bugs" too. I'd wager even more so since it isn't runnable and has much less eyeballs. But you have a point that a traditional spec can underspecify behaviour in a way that is not possible in Rust itself. But I content that underspecified behavior in a programming language should be avoided.
    - im3w1l 4y ago
      At least if you have a spec and an implementation, you have two descriptions. We can then have some hope that any bug isn't present in both of them, and we can decide which of the two was more reasonable.
      - rowanG077 4y ago
        We do (or very soon will) have that for Rust as well with the gcc front end.
  - tialaramex 4y ago
    Because of the Crater runs which Mara mentions, the Rust teams are actually in a good place to judge what the right call here is. In practice, for a programming language, even something relatively simple like C, the specification is too woolly to be enough, and so the fact of what compilers actually do matters. So Rust having a specification would not magically prevent this problem. Rust's Crater runs allow sunlight from the real world to intrude into decision making. Suppose it is discovered that although the docs say X doesn't happen, actually the compiler does X. Instead of "I bet lots of people rely on X, we must change the specs to match" versus "I bet everybody trusted our spec, which says X doesn't happen, fix the compiler" we have real facts. "Popular crates cool_stuff and jims_other_stuff both rely on X in versions from the last 18 months. Their authors both said they tried this and assumed the documentation was wrong. We should update the documentation to match reality" vs "There's only one crate which uses X, it's a test case in a sub-component of obscure_doodad 0.0.1 from 2017, it appears to receive no usage, and two of the other test cases in obscure_doodad fail on current Rust, so perhaps it is just broken anyway? We should just fix the compiler" The C++ people couldn't have done this twenty years ago. Today they probably could attempt this with various Free Software C++ codebases out there (e.g. GitHub's C++ projects), but as well as considerable technical effort to attempt this, it would be a political burden because lots of non-Free stuff believes it has secret sauce and so vague and unsourced claims about what does or doesn't exist in proprietary C++ are a big problem for compatibility. If you're on team "Don't change X" of course you'll claim huge industrial partners you've seen rely on X in code you can't show anybody. If you're on team "X is obsolete garbage no-uses" you'll claim it's apparent nobody relies on X. This is much less true for Rust. There obviously is proprietary Rust, including in-house projects and stuff that's deliberately proprietary rather than just nobody cared, but Crate covers a lot of what's out there.
duped 4y ago
Something I find interesting about this discussion is that Rust seems to be held to a significantly higher standard than any other language developed in the last 30 years. I don't think Rust needs a standard. I don't think it needs a stable ABI. I don't think it needs a second or third implementation. My argument is pretty simple: there are dozens of other language projects that have none of these things and have seen a lot of success. Yet these criticisms are rare of other languages - I don't think I've ever seen someone lament that Swift or Go or Typescript or Dart or $ANY_LANG don't have an ISO spec. That doesn't mean myself and others can't see the value in these features but it does seem to be a weird critique. The better question is to state more explicitly the preconditions: C and C++ have a specification. Does Rust need one before it can replace C and C++ in projects? And I think the answer is "it depends but probably not for most projects."
- trimistermota 4y ago
  Very few of those languages are used in certified code.
  - steveklabnik 4y ago
    And yet, a version of rustc is well on its way to being certified. Standardization is not required for certification.
- mjw1007 4y ago
  I don't think people who are asking for an accurate description of Rust are holding it to a higher standard than other languages. Rust's current reference docs, more than seven years after Rust 1.0 was released, are much weaker than the first version of the Java specification (which was published seven _months_ after JDK 1.0). The place where it seems to me that there's a strange inconsistency is inside the Rust community: when discussing package management or compiler error messages or tutorial documentation or pretty much anything else I can think of, the there seems to be general agreement that Rust should aim to be best in class. But when it comes to complete-and-correct documentation, I hear voices saying "are we sure we need this?", and "we're no worse than C was in 1985", and "we shouldn't let writing documentation slow down releasing new features".
singularity2001 4y ago
please don't standardize it before some ugly warts are removed

40 points by georgehill 4y ago

With GCC adding Rust support there is no longer one "official" compiler. In many people's eyes GCC will be considered "the" Rust compiler. If Rust wants to supplant C in embedded, a specification is required. I'm honestly surprised Linux is accepting unspecified code into the kernel with the addition of Rust.

Macha 4y ago
Linux's C code doesn't stick to the C standard either, it uses plenty of GCC extensions, and it's not clear Clang would have implemented all of them if it wasn't for their use in the Linux kernel. So a language specification is not that high on the Linux priorities list.
tialaramex 4y ago
Linux doesn't even obey ISO C's Memory Model. Linux was multi-processor many years before ISO C11 documents a Memory Model (the same one as C++ 11) and so it had many years to decide how this stuff should work in practice on actual multi-processor hardware. https://lwn.net/Articles/718628/ https://lwn.net/Articles/718628/ The Linux model and the C++ 11 (as subsequently modified) model are similar in the sense that they respect how the CPU actually works, necessarily in the case of Linux and for practical low level C or C++, but in details they differ, sometimes for good reason and sometimes just because Linux was here first.
- simplotek 4y ago
  > Linux doesn't even obey ISO C's Memory Model. Red herring. If I recall correctly, Linus publicly stated a number of times that C's memory model is relevant for userspace code but OS development has its own requirements. Amusingly enough, I recall that this discussion was about Rust, and the way that Rust proponents advocated pushing Rust's memory model onto Linux.
madmoose 4y ago
> With GCC adding Rust support there is no longer one "official" compiler. No, there's will still only be one official compiler – the one written and provided by The Rust Project. > If Rust wants to supplant C in embedded, a specification is required. You're getting your history backwards. C did not become successful because of its specification, it got a specification because it was successful. Similarly, if Rust becomes successful enough, it will probably get a specification. But the popularity will drive the work on a specification, not the other way around.
- simplotek 4y ago
  > C did not become successful because of its specification, it got a specification because it was successful. I disagree. The need for a standard specification of what the C programming language is sprung from the need to ensure that multiple independent compiler implementations were actually compatible and supported the same sets of features. If a nonstandard C ecosystem had to endure the pain of either targeting products from specific vendors or waste time maintaining a caniuse database of C features, the amount of wasted effort to just keep code building would make things too challenging and troublesome to maintain. Consequently, we would see gradual fragmentation both within the C-like ecosystem and in other potential C-like successors that ink offered minor changes.

tialaramex 4y ago

As well as obeying Betteridge's Law, Mara's article hits a few frequent mistakes that crop up in Rust discussions: e.g. how Editions are different (I would say better) than versions of a standard language like C++. One thing I think is worth more reflection is: Are there specific things such a Specification must cover, or is it enough, as it seems C and C++ felt, to just specify some of the language and leave the rest unacknowledged ? For example, ANSI and ISO C significantly pre-date the memory model we're all now comfortable C implements. They don't offer a different memory model, the specification just never mentions what's going on at all in this respect. If you wrote concurrent software in C in, say, 1996 (which I did) then eh, it does whatever it is that it happens to do. The ISO standard document has no view. Right now, Rust "pretty blatantly just inherits the memory model for atomics from C++20. This is not due to this model being particularly excellent or easy to understand. Indeed, this model is quite complex and known to have several flaws. Rather, it is a pragmatic concession" (quoting the Nomicon). Is that good enough? If Aria's Strict Provenance experiment goes well, how much of that should be specified? As much as possible? As little as possible?

rowanG077 4y ago

Isn't the rustc compiler the runnable spec? I don't particularly see the need to build a parallel spec just for people who don't want to read the code.

conradludgate 4y ago
I think this logic is flawed. If we find a bug in the compiler, is that now a guaranteed behaviour as being the implicit spec? I think a spec is different in a way that allows it to document expected behaviour vs implemented behaviour
- rowanG077 4y ago
  A traditional spec doesn't fix that issue it has "bugs" too. I'd wager even more so since it isn't runnable and has much less eyeballs. But you have a point that a traditional spec can underspecify behaviour in a way that is not possible in Rust itself. But I content that underspecified behavior in a programming language should be avoided.
  - im3w1l 4y ago
    At least if you have a spec and an implementation, you have two descriptions. We can then have some hope that any bug isn't present in both of them, and we can decide which of the two was more reasonable.
    - rowanG077 4y ago
      We do (or very soon will) have that for Rust as well with the gcc front end.
- tialaramex 4y ago
  Because of the Crater runs which Mara mentions, the Rust teams are actually in a good place to judge what the right call here is. In practice, for a programming language, even something relatively simple like C, the specification is too woolly to be enough, and so the fact of what compilers actually do matters. So Rust having a specification would not magically prevent this problem. Rust's Crater runs allow sunlight from the real world to intrude into decision making. Suppose it is discovered that although the docs say X doesn't happen, actually the compiler does X. Instead of "I bet lots of people rely on X, we must change the specs to match" versus "I bet everybody trusted our spec, which says X doesn't happen, fix the compiler" we have real facts. "Popular crates cool_stuff and jims_other_stuff both rely on X in versions from the last 18 months. Their authors both said they tried this and assumed the documentation was wrong. We should update the documentation to match reality" vs "There's only one crate which uses X, it's a test case in a sub-component of obscure_doodad 0.0.1 from 2017, it appears to receive no usage, and two of the other test cases in obscure_doodad fail on current Rust, so perhaps it is just broken anyway? We should just fix the compiler" The C++ people couldn't have done this twenty years ago. Today they probably could attempt this with various Free Software C++ codebases out there (e.g. GitHub's C++ projects), but as well as considerable technical effort to attempt this, it would be a political burden because lots of non-Free stuff believes it has secret sauce and so vague and unsourced claims about what does or doesn't exist in proprietary C++ are a big problem for compatibility. If you're on team "Don't change X" of course you'll claim huge industrial partners you've seen rely on X in code you can't show anybody. If you're on team "X is obsolete garbage no-uses" you'll claim it's apparent nobody relies on X. This is much less true for Rust. There obviously is proprietary Rust, including in-house projects and stuff that's deliberately proprietary rather than just nobody cared, but Crate covers a lot of what's out there.

duped 4y ago

Something I find interesting about this discussion is that Rust seems to be held to a significantly higher standard than any other language developed in the last 30 years. I don't think Rust needs a standard. I don't think it needs a stable ABI. I don't think it needs a second or third implementation. My argument is pretty simple: there are dozens of other language projects that have none of these things and have seen a lot of success. Yet these criticisms are rare of other languages - I don't think I've ever seen someone lament that Swift or Go or Typescript or Dart or $ANY_LANG don't have an ISO spec. That doesn't mean myself and others can't see the value in these features but it does seem to be a weird critique. The better question is to state more explicitly the preconditions: C and C++ have a specification. Does Rust need one before it can replace C and C++ in projects? And I think the answer is "it depends but probably not for most projects."

trimistermota 4y ago
Very few of those languages are used in certified code.
- steveklabnik 4y ago
  And yet, a version of rustc is well on its way to being certified. Standardization is not required for certification.
mjw1007 4y ago
I don't think people who are asking for an accurate description of Rust are holding it to a higher standard than other languages. Rust's current reference docs, more than seven years after Rust 1.0 was released, are much weaker than the first version of the Java specification (which was published seven _months_ after JDK 1.0). The place where it seems to me that there's a strange inconsistency is inside the Rust community: when discussing package management or compiler error messages or tutorial documentation or pretty much anything else I can think of, the there seems to be general agreement that Rust should aim to be best in class. But when it comes to complete-and-correct documentation, I hear voices saying "are we sure we need this?", and "we're no worse than C was in 1985", and "we shouldn't let writing documentation slow down releasing new features".

singularity2001 4y ago

please don't standardize it before some ugly warts are removed