7 ms·

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 las

by 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".
- tialaramex 4y ago
  > 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". Topic matters. Take the Guaranteed Niche Optimisation. Many users rely on Rust's promise that Option<&T> is the same size as &T for example, that's the "Guaranteed Niche Optimisation" (the niche in &T is that it can't be a NULL pointer) If the specification didn't mention this at all, or said eh, we can't promise anything, that would be a problem. I've no doubt serious Rust users would demand this get written down properly. But the exact details of the Guarantee aren't so important. Far more people care that Option<&T> is the same size as &T, than care about, say, Option<NonZeroU32> let alone more obscure types that are in practice optimised. If it turned out the guarantee was narrower than you expected, but only for some type you never use, is that important? What if Option<Infallible> wasn't a ZST due to a compiler bug? I'd guess Rust internal tests would notice, but if not I'm not sure how much real software would care. If somebody can spend next week either carefully documenting exactly what the Guaranteed Niche Optimisation is, all the fine details, or implementing a cute niche optimiser trick which turns out to make the most popular JSON parser use 1% less RAM and 5% less CPU, the latter is just clearly the better deal.
  - mjw1007 4y ago
    From where I stand, this is just one more example of members of the Rust community working hard to find excuses for not having documentation. To the extent that people are relying on the common cases of the niche optimisation taking place: yes, the Rust description should be documenting what people may rely on, and should have been documenting it for years. In order to do that there's absolutely no need to describe the fine details of exactly where the optimisation currently applies.
    - Gankra 4y ago
      The null pointer optimization is documented in many places, here's one official instance I published in 2015: https://doc.rust-lang.org/nomicon/repr-rust.html https://doc.rust-lang.org/nomicon/repr-rust.html There are many random details of a language that are "important" and they get documented all over the place. If it was all under "THE REFERENCE" and was a 500 page PDF, would the information actually be more discoverable? How would you even know to look up what you don't know? Are you going to read the reference cover to cover before writing hello world?
simplotek 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. It's not. Rust lags way behind the standards help for decades by languages which the Rust community repeatedly claims Rust is supposed to replace. Rust has in no way, shape or form anything resembling an effort to specify it's core language and standard library in an international standard. Standards are critical because they are objective, clear, and well thought through specifications of how the language works now and anywhere, including and specially clean room implementations. > 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. Most of the top programming languages already are specified in international standards. Including JavaScript. https://en.wikipedia.org/wiki/Category:Programming_languages_with_an_ISO_standard https://en.wikipedia.org/wiki/Category:Programming_languages... Also, all of your examples, arguably with the exception of Go, are still in very early and unstable development stages, with projects repeatedly introducing breaking changes. If even the language designers don't make up their minds over what goes into it then we can't really talk about stability.
- thethirdone 4y ago
  >> 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. > Most of the top programming languages already are specified in international standards. Including JavaScript. > https://en.wikipedia.org/wiki/Category:Programming_languages https://en.wikipedia.org/wiki/Category:Programming_languages... > Also, all of your examples, arguably with the exception of Go, are still in very early and unstable development stages, with projects repeatedly introducing breaking changes. If even the language designers don't make up their minds over what goes into it then we can't really talk about stability. Java, Python, and PHP are all widely used and do not have ISO standards.

by duped 4y ago

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".

tialaramex 4y ago
> 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". Topic matters. Take the Guaranteed Niche Optimisation. Many users rely on Rust's promise that Option<&T> is the same size as &T for example, that's the "Guaranteed Niche Optimisation" (the niche in &T is that it can't be a NULL pointer) If the specification didn't mention this at all, or said eh, we can't promise anything, that would be a problem. I've no doubt serious Rust users would demand this get written down properly. But the exact details of the Guarantee aren't so important. Far more people care that Option<&T> is the same size as &T, than care about, say, Option<NonZeroU32> let alone more obscure types that are in practice optimised. If it turned out the guarantee was narrower than you expected, but only for some type you never use, is that important? What if Option<Infallible> wasn't a ZST due to a compiler bug? I'd guess Rust internal tests would notice, but if not I'm not sure how much real software would care. If somebody can spend next week either carefully documenting exactly what the Guaranteed Niche Optimisation is, all the fine details, or implementing a cute niche optimiser trick which turns out to make the most popular JSON parser use 1% less RAM and 5% less CPU, the latter is just clearly the better deal.
- mjw1007 4y ago
  From where I stand, this is just one more example of members of the Rust community working hard to find excuses for not having documentation. To the extent that people are relying on the common cases of the niche optimisation taking place: yes, the Rust description should be documenting what people may rely on, and should have been documenting it for years. In order to do that there's absolutely no need to describe the fine details of exactly where the optimisation currently applies.
  - Gankra 4y ago
    The null pointer optimization is documented in many places, here's one official instance I published in 2015: https://doc.rust-lang.org/nomicon/repr-rust.html https://doc.rust-lang.org/nomicon/repr-rust.html There are many random details of a language that are "important" and they get documented all over the place. If it was all under "THE REFERENCE" and was a 500 page PDF, would the information actually be more discoverable? How would you even know to look up what you don't know? Are you going to read the reference cover to cover before writing hello world?

simplotek 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. It's not. Rust lags way behind the standards help for decades by languages which the Rust community repeatedly claims Rust is supposed to replace. Rust has in no way, shape or form anything resembling an effort to specify it's core language and standard library in an international standard. Standards are critical because they are objective, clear, and well thought through specifications of how the language works now and anywhere, including and specially clean room implementations. > 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. Most of the top programming languages already are specified in international standards. Including JavaScript. https://en.wikipedia.org/wiki/Category:Programming_languages_with_an_ISO_standard https://en.wikipedia.org/wiki/Category:Programming_languages... Also, all of your examples, arguably with the exception of Go, are still in very early and unstable development stages, with projects repeatedly introducing breaking changes. If even the language designers don't make up their minds over what goes into it then we can't really talk about stability.

thethirdone 4y ago
>> 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. > Most of the top programming languages already are specified in international standards. Including JavaScript. > https://en.wikipedia.org/wiki/Category:Programming_languages https://en.wikipedia.org/wiki/Category:Programming_languages... > Also, all of your examples, arguably with the exception of Go, are still in very early and unstable development stages, with projects repeatedly introducing breaking changes. If even the language designers don't make up their minds over what goes into it then we can't really talk about stability. Java, Python, and PHP are all widely used and do not have ISO standards.