5 ms·

The problem with analyzing stuff like this about Rust, is that even Rust itself has no idea how it works, or what syntax and semantics actually mean. Rust does

The problem with analyzing stuff like this about Rust, is that even Rust itself has no idea how it works, or what syntax and semantics actually mean. Rust doesn't merely lack a language standard, its reference and advanced documentation is also a very unfunny joke. You can learn just enough to have some idea of what you're doing, and then you're stuck huffing unicorn queefs because nobody including the compiler devs knows the exact rules on how syntax is supposed to work. Magical shortcuts, syntax, and borrow checker tricks are added and removed at random with no rhyme or reason, and Rust severely punishes the programmer for wanting to know how the language actually works, since there are usually no answers, or worse, wrong answers, for them to find. I still use Rust because the memory safety without a GC is wonderful, but please, don't even try to make it look like Rust has some official documentation or behavior. It most definitely does not, and what really disturbs me is how so many of the Rust community don't even want a standard. So OP, everything you've just done, will be rendered obsolete and woefully wrong in a couple years when Rust serves up another opaque unicorn-burger.

deleted 5y ago
[deleted]
nynx 5y ago
What? Are you sure you're looking at the right language? Or maybe you've confused stable rust and nightly rust?
- Subsentient 5y ago
  No, I'm definitely on the right language. For example, lots of magical implicit reborrows with fuck all in the documentation, pattern matches and specifiers with no formal behavior defined, lints that change constantly. I do use nightly generally, simply because stable is crippled in features, but the same issues apply to stable. I should mention that even when they adjust these things in a stable release, they never fix the documentation to reflect it. And in the case of many of these things, they aren't documented at all, except perhaps a couple sentences about their existence.
  - myrrlyn 5y ago
    PRs welcome!
    - Subsentient 5y ago
      These issues cannot be fixed by merely updating the docs for a few items. (and frankly I don't contribute much to big FOSS projects because I've had bad experiences with big projects before) This can only be fixed by A. Requiring that all syntax changes, no matter how small, are fully documented before they reach stable or even beta, and B. Eventual standardization, even if the reference implementation ends up being more cutting edge. Rust devs also need to think more about how they're going to document a feature before they add it. Like for many of the implicit reborrows, they're done in non-obvious places and not done in others, with no pattern to where it's done and where it's not. That kind of implementation is extremely painful to document or standardize. Rust needs to think more in terms of rules for syntax, rather than instances of a particular shortcut. Rather than adding a standalone instance, you should edit the rules so that instance is covered.
      - ben0x539 5y ago
        Are you interested in standardization for its own sake or as a forcing function for exhaustive documentation?
        Subsentient 5y ago
        Both, though mostly documentation. To me, a standard is the documentation. The fact I have to read rustc source to find syntax is frankly an abomination. A standard defines syntax and grammar in ways that a html reference page never does. It doesn't matter as much for "fluffy" languages like Python or Lua, but it's very important for a systems language. I also want standardization to make writing alternative conforming compilers easier. I strongly dislike the attitude of some Rust maintainers, and a standard is a useful tool to forcibly remove some level of control from their hands.
    - CJefferson 5y ago
myrrlyn 5y ago
every time this comes up i just have to ask - what do you think a language standard is or does - what languages with standards do you think standardization has helped (this is a trick question! do not answer "c" or "c++"!) - in which languages with standards is a plurality of code written to that standard? (this is also a trick question! do not answer "c", "c++", or "javascript"!)
- nicebyte 5y ago
  a "language standard" is something i can use to hold implementation developers accountable. it doesn't matter if it's an actual international standard, or just a document on the internet. I want a dry, exhaustive and systematic description of the features and intended behaviors. Refer to the Vulkan spec (https://www.khronos.org/registry/vulkan/specs/1.2/html/ https://www.khronos.org/registry/vulkan/specs/1.2/html/) to get an example of what i consider a good specification. The rust docs don't currently meet that bar. They're quite WIP, and I imagine someone hitting a particular edge case will not necessarily be well equipped to understand whether the behavior they're observing is intended, a bug in the implementation or something else entirely.
  - mjw1007 5y ago
    Yes. There is a great deal of written information about Rust-the-language which exists only in compiler comments, RFCs, bug reports and internals.rust-lang.org threads (often slightly stale in all cases). It's Rust's greatest weakness. But "every time this comes up" the discussion somehow gets sidetracked into arguments about standardisation, even in cases (such as this thread) when it's clear that what the ranter cares about is accurate documentation.
  - nyanpasu64 5y ago
    a "language standard" is something i can use to hold implementation and library developers accountable. I want a dry, exhaustive and systematic description of what code is legal and illegal. Instead we have arguments over whether some unsafe code found in the wild is UB and will break once LLVM fixes noalias for real this time, not UB (eg. holding raw pointers into a Vec while the Vec moves without reallocating), compiles fine but may break in the future (eg. holding raw pointers into a Box while the Box moves), compiles fine but the Stacked Borrows rules forbid it but will eventually be changed to not forbid it (Pin). Instead of a firm contract between the compiler and the programmer, we have unsafe code guidelines which is the language team's best idea at the moment for what is legal or not. Even though C++ code in the wild is filled with standard violations, I like having a standard explaining what rules exist, so developers can reason about them, and I can use them to tell other developers to change their code because their code is invalid. (In practice I don't know if violating strict aliasing through reinterpret_cast rather than bit_cast can lead to compilation errors, and sadly std::variant can miscompile due to broken aliasing optimizations in library code even with valid user code: https://www.reddit.com/r/cpp/comments/j7gn2d/stdvariant_is_broken_in_clang_and_it_exposes_how/ https://www.reddit.com/r/cpp/comments/j7gn2d/stdvariant_is_b....) Currently, not all unsafe Rust can be classified as either valid (make sure the compiler doesn't break it) or invalid (change the code until it's valid), though there are some cases where unsafe Rust is clearly invalid. Maybe it's a temporary state while the language team makes decisions based on how the unsafe library ecosystem progresses. Maybe the language team has no plans to put the language on a firm groundwork defining exactly what is legal or not, which I find uncomfortable (though maybe others feel more comfortable with it). In any case, there's not that much practical impact on the quality of code being written and binaries being produced, but it still hurts to see people building castles on uncertain foundations.
pitterpatter 5y ago
>Magical shortcuts, syntax, and borrow checker tricks are added and removed at random with no rhyme or reason Everything else aside for now, this is just patently false. There's a well-established RFC process for any such changes to the language/compiler/standard library.
jokethrowaway 5y ago
I assume your criticism revolves around breaking changes as what you mention is simply not true; there is plenty of documentation and language definition and I never found an issue. Development languages evolve all the time. It's normal, the same happens to human languages. I can't even say Rust is changing that much (especially compared to JS, my main work language).
bob1029 5y ago
Documentation and roadmap are the 2 make-or-break things I look for in a language/framework/tool. If one of these things is not satisfied, I have an incredibly hard time convincing myself to invest time. I have taken a look at the Rust documentation, and I just can't see myself participating at this point because of it. The roadmap is also unclear to me. I google 'Rust Roadmap', and guess what the first result is? https://rust.nolt.io/roadmap https://rust.nolt.io/roadmap So far a video game's roadmap is ranked above that of this language. I had to search for 'rust-lang roadmap' to get a good top hit... Which brought me here: https://blog.rust-lang.org/2020/09/03/Planning-2021-Roadmap.html https://blog.rust-lang.org/2020/09/03/Planning-2021-Roadmap.... > The core team is beginning to think about the 2021 Roadmap, and we want to hear from the community. We’re going to be running two parallel efforts over the next several weeks: the 2020 Rust Survey, to be announced next week, and a call for blog posts. A call for blog posts. Beginning to think about... As a .NET developer, this honestly sounds like a dumpster fire to me. Who is actually in charge? What is the vision for 2025? How do you explain your software technology roadmap to your customers when you are using Rust and have to operate in contract lifetimes of 5+ years? Clearly, I don't know the first goddamn thing about the Rust ecosystem or why I would want to use it. I am just a dirty .NET plebian looking in from the outside. It doesn't look very compelling right now. Can someone correct my perspective on this? I am open to it. There must be some value I am missing. Maybe Rust just isn't for the "enterprise", or whatever boring niche box I seem to be stuck living in these days. There are obviously use cases and happy developers out there. Don't let me get in your way.
- steveklabnik 5y ago
  > Who is actually in charge? https://www.rust-lang.org/ https://www.rust-lang.org/ has a big old "governance" header on it, which links to this page https://www.rust-lang.org/governance https://www.rust-lang.org/governance That page explains the process, who is in charge of it, and links to the roadmap for this year. 2021 is a pretty chill year for Rust overall. The project is largely focused inward, the Foundation is newly launched and figuring itself out, the edition is going to be much smaller than in 2018, and most things that are shipping are polish, bugfixes, and small API improvements. > What is the vision for 2025? We only plan in year increments; it is extremely difficult to do longer-term forecasting than that in an open source project. To be honest, even yearly is hard to do with more detail than high-level goals.

deleted 5y ago

[deleted]

nynx 5y ago

What? Are you sure you're looking at the right language? Or maybe you've confused stable rust and nightly rust?

Subsentient 5y ago
No, I'm definitely on the right language. For example, lots of magical implicit reborrows with fuck all in the documentation, pattern matches and specifiers with no formal behavior defined, lints that change constantly. I do use nightly generally, simply because stable is crippled in features, but the same issues apply to stable. I should mention that even when they adjust these things in a stable release, they never fix the documentation to reflect it. And in the case of many of these things, they aren't documented at all, except perhaps a couple sentences about their existence.
- myrrlyn 5y ago
  PRs welcome!
  - Subsentient 5y ago
    These issues cannot be fixed by merely updating the docs for a few items. (and frankly I don't contribute much to big FOSS projects because I've had bad experiences with big projects before) This can only be fixed by A. Requiring that all syntax changes, no matter how small, are fully documented before they reach stable or even beta, and B. Eventual standardization, even if the reference implementation ends up being more cutting edge. Rust devs also need to think more about how they're going to document a feature before they add it. Like for many of the implicit reborrows, they're done in non-obvious places and not done in others, with no pattern to where it's done and where it's not. That kind of implementation is extremely painful to document or standardize. Rust needs to think more in terms of rules for syntax, rather than instances of a particular shortcut. Rather than adding a standalone instance, you should edit the rules so that instance is covered.
    - ben0x539 5y ago
      Are you interested in standardization for its own sake or as a forcing function for exhaustive documentation?
      - Subsentient 5y ago
        Both, though mostly documentation. To me, a standard is the documentation. The fact I have to read rustc source to find syntax is frankly an abomination. A standard defines syntax and grammar in ways that a html reference page never does. It doesn't matter as much for "fluffy" languages like Python or Lua, but it's very important for a systems language. I also want standardization to make writing alternative conforming compilers easier. I strongly dislike the attitude of some Rust maintainers, and a standard is a useful tool to forcibly remove some level of control from their hands.
  - CJefferson 5y ago

myrrlyn 5y ago

every time this comes up i just have to ask - what do you think a language standard is or does - what languages with standards do you think standardization has helped (this is a trick question! do not answer "c" or "c++"!) - in which languages with standards is a plurality of code written to that standard? (this is also a trick question! do not answer "c", "c++", or "javascript"!)

nicebyte 5y ago
a "language standard" is something i can use to hold implementation developers accountable. it doesn't matter if it's an actual international standard, or just a document on the internet. I want a dry, exhaustive and systematic description of the features and intended behaviors. Refer to the Vulkan spec (https://www.khronos.org/registry/vulkan/specs/1.2/html/ https://www.khronos.org/registry/vulkan/specs/1.2/html/) to get an example of what i consider a good specification. The rust docs don't currently meet that bar. They're quite WIP, and I imagine someone hitting a particular edge case will not necessarily be well equipped to understand whether the behavior they're observing is intended, a bug in the implementation or something else entirely.
- mjw1007 5y ago
  Yes. There is a great deal of written information about Rust-the-language which exists only in compiler comments, RFCs, bug reports and internals.rust-lang.org threads (often slightly stale in all cases). It's Rust's greatest weakness. But "every time this comes up" the discussion somehow gets sidetracked into arguments about standardisation, even in cases (such as this thread) when it's clear that what the ranter cares about is accurate documentation.
- nyanpasu64 5y ago
  a "language standard" is something i can use to hold implementation and library developers accountable. I want a dry, exhaustive and systematic description of what code is legal and illegal. Instead we have arguments over whether some unsafe code found in the wild is UB and will break once LLVM fixes noalias for real this time, not UB (eg. holding raw pointers into a Vec while the Vec moves without reallocating), compiles fine but may break in the future (eg. holding raw pointers into a Box while the Box moves), compiles fine but the Stacked Borrows rules forbid it but will eventually be changed to not forbid it (Pin). Instead of a firm contract between the compiler and the programmer, we have unsafe code guidelines which is the language team's best idea at the moment for what is legal or not. Even though C++ code in the wild is filled with standard violations, I like having a standard explaining what rules exist, so developers can reason about them, and I can use them to tell other developers to change their code because their code is invalid. (In practice I don't know if violating strict aliasing through reinterpret_cast rather than bit_cast can lead to compilation errors, and sadly std::variant can miscompile due to broken aliasing optimizations in library code even with valid user code: https://www.reddit.com/r/cpp/comments/j7gn2d/stdvariant_is_broken_in_clang_and_it_exposes_how/ https://www.reddit.com/r/cpp/comments/j7gn2d/stdvariant_is_b....) Currently, not all unsafe Rust can be classified as either valid (make sure the compiler doesn't break it) or invalid (change the code until it's valid), though there are some cases where unsafe Rust is clearly invalid. Maybe it's a temporary state while the language team makes decisions based on how the unsafe library ecosystem progresses. Maybe the language team has no plans to put the language on a firm groundwork defining exactly what is legal or not, which I find uncomfortable (though maybe others feel more comfortable with it). In any case, there's not that much practical impact on the quality of code being written and binaries being produced, but it still hurts to see people building castles on uncertain foundations.

pitterpatter 5y ago

>Magical shortcuts, syntax, and borrow checker tricks are added and removed at random with no rhyme or reason Everything else aside for now, this is just patently false. There's a well-established RFC process for any such changes to the language/compiler/standard library.

jokethrowaway 5y ago

I assume your criticism revolves around breaking changes as what you mention is simply not true; there is plenty of documentation and language definition and I never found an issue. Development languages evolve all the time. It's normal, the same happens to human languages. I can't even say Rust is changing that much (especially compared to JS, my main work language).

bob1029 5y ago

Documentation and roadmap are the 2 make-or-break things I look for in a language/framework/tool. If one of these things is not satisfied, I have an incredibly hard time convincing myself to invest time. I have taken a look at the Rust documentation, and I just can't see myself participating at this point because of it. The roadmap is also unclear to me. I google 'Rust Roadmap', and guess what the first result is? https://rust.nolt.io/roadmap https://rust.nolt.io/roadmap So far a video game's roadmap is ranked above that of this language. I had to search for 'rust-lang roadmap' to get a good top hit... Which brought me here: https://blog.rust-lang.org/2020/09/03/Planning-2021-Roadmap.html https://blog.rust-lang.org/2020/09/03/Planning-2021-Roadmap.... > The core team is beginning to think about the 2021 Roadmap, and we want to hear from the community. We’re going to be running two parallel efforts over the next several weeks: the 2020 Rust Survey, to be announced next week, and a call for blog posts. A call for blog posts. Beginning to think about... As a .NET developer, this honestly sounds like a dumpster fire to me. Who is actually in charge? What is the vision for 2025? How do you explain your software technology roadmap to your customers when you are using Rust and have to operate in contract lifetimes of 5+ years? Clearly, I don't know the first goddamn thing about the Rust ecosystem or why I would want to use it. I am just a dirty .NET plebian looking in from the outside. It doesn't look very compelling right now. Can someone correct my perspective on this? I am open to it. There must be some value I am missing. Maybe Rust just isn't for the "enterprise", or whatever boring niche box I seem to be stuck living in these days. There are obviously use cases and happy developers out there. Don't let me get in your way.

steveklabnik 5y ago
> Who is actually in charge? https://www.rust-lang.org/ https://www.rust-lang.org/ has a big old "governance" header on it, which links to this page https://www.rust-lang.org/governance https://www.rust-lang.org/governance That page explains the process, who is in charge of it, and links to the roadmap for this year. 2021 is a pretty chill year for Rust overall. The project is largely focused inward, the Foundation is newly launched and figuring itself out, the edition is going to be much smaller than in 2018, and most things that are shipping are polish, bugfixes, and small API improvements. > What is the vision for 2025? We only plan in year increments; it is extremely difficult to do longer-term forecasting than that in an open source project. To be honest, even yearly is hard to do with more detail than high-level goals.