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.
- 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"!)
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.
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.
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_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.
Personally I disagree. If you want to write freely aliasing code, I think it's better to use &UnsafeCell or &Cell or &RefCell, perhaps with an Arc (or my AliasPtr crate) instead of trying to convince rustc that &mut isn't exclusive.
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).
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?
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....
> 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.
https://www.rust-lang.org/ has a big old "governance" header on it, which links to this page 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.
Why not wait and figure that out when we get there? The world is changing too fast now; consider that any vision for 2020 written in 2015 would probably have been useless by the time we were actually in 2020.
Edit: Also consider that updates to Rust probably don't have nearly as big an effect on your customers as changes to .NET, especially the old .NET Framework which was shipped as a shared runtime environment on the customers' machines. Assuming you ship binaries to your customers, Rust probably isn't even visible to them.
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.
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.
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.
The top talks about lt, le, gt, ge, but then the docs below talk about '<' and '>', which I assume are lt and gt? But then there seems to be no requirements in le and ge? I assume everything needs to be consistent?
Also (relating to auto-ref), why does 'a<b' work, when the trait takes a reference?
EDIT: Some of this is revealed if I scroll down and look at the definitions of 'lt' and friends, but I'm already pretty confused at the top.
EDIT 2: This really wasn't worth the effort of defending, but I made an issue with my comments on PartialOrd.
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.