News for hackers. Stuff that matters.
Re:Understanding Rust futures by going way too deep by nynx on Monday July 26, 2021 @09:26AM (#27959058)
What? Are you sure you're looking at the right language? Or maybe you've confused stable rust and nightly rust?
Re:Understanding Rust futures by going way too deep by Subsentient on Monday July 26, 2021 @09:28AM (#27959086)
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.

Re:Understanding Rust futures by going way too deep by myrrlyn on Monday July 26, 2021 @09:39AM (#27959205)
PRs welcome!
Re:Understanding Rust futures by going way too deep by Subsentient on Monday July 26, 2021 @10:02AM (#27959446)
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.

Re:Understanding Rust futures by going way too deep by ben0x539 on Monday July 26, 2021 @12:55PM (#27961821)
Are you interested in standardization for its own sake or as a forcing function for exhaustive documentation?
Re:Understanding Rust futures by going way too deep by Subsentient on Monday July 26, 2021 @04:54PM (#27965330)
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.

Re:Understanding Rust futures by going way too deep by CJefferson on Monday July 26, 2021 @11:36AM (#27960753)
While this rant is excessive, I do see some of the annoyance, for example looking at: https://doc.rust-lang.org/core/cmp/trait.PartialOrd.html

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.