Hacker News new | comments | show | ask | jobs | submit login
Rust turns three (rust-lang.org)
97 points by steveklabnik 4 months ago | hide | past | web | favorite | 17 comments



The 1.0 release still feels like it was just yesterday. :)

As with any mention of Rust 2018 and the rustfix tool, I want to emphasize how seriously compatibility is being taken:

> You can use old editions indefinitely on new compilers; editions are opt-in.

> Editions are set on a per-crate basis and can be mixed and matched; you can be on a different edition from your dependencies.

> Warning-free code in one edition must compile, and have the same behavior, on the next.

> Edition-related warnings, e.g. that an identifier will become a keyword in the next edition, must be easily fixable via an automated migration tool (rustfix). Only a small minority of crates should require any manual work to opt in to a new edition, and that manual work must be minimal.

> Most new features are edition-independent, and will be usable on new compilers even when an older edition is selected.

https://blog.rust-lang.org/2018/03/12/roadmap.html


> Most new features are edition-independent, and will be usable on new compilers even when an older edition is selected.

What happens when you have specified an older edition, but use a feature from a newer edition (possibly without realizing it's from a newer edition), it works fine on your newer edition compiler, then try and build it on a compiler supporting only the older edition? Is that a potential issue or am I interpreting it incorrectly? It kinda seems like maybe features should be edition dependent.


It's not 100% clear to me what you're seeing as the issue here.

> but use a feature from a newer edition (possibly without realizing it's from a newer edition)

You'd have to specify the newer edition for it to work.

> try and build it on a compiler supporting only the older edition?

This is kind of a moot point given that there's only one real compiler right now, but it would fail to compile.


> You'd have to specify the newer edition for it to work.

That seems to contradict this:

> Most new features are edition-independent, and will be usable on new compilers even when an older edition is selected.

I understand it's currently a moot point, I'm just trying to understand if I'm interpreting it correctly.


If it's an edition-independent feature, then it doesn't require the newer edition, so a compiler that doesn't support the new edition wouldn't have any problems.

Maybe it would help to step through a strawman?

Let's say that "impl Trait" didn't land last week, but lands six months from now, after the 2018 edition ships. Alice is working on a library project using the 2015 edition. She uses "impl Trait". Since it doesn't require the 2018 edition, it just works. Bob uses Alice's library, and uses a compiler that doesn't support Rust 2018. That's fine, as Alice hasn't used any 2018 specific things.

That's my understanding of the scenario you're talking about. Did I get it right?

The other scenario would be this:

It's 2019. Alice is working on a library project using the 2015 edition. She tries to use the "catch" keyword, which requires edition 2018. When she tries to use it, her code will fail to compile. She has two choices: 1. not use the feature 2. update to edition 2018. If she chooses the latter, when Bob tries to use her library later, but his compiler doesn't support the 2018 edition, it will fail to compile.

This is basically all of the usual backwards and forwards compatibility stuff, even without editions. If you try to use ? on a 1.0 version of rustc, your code won't compile, as that was added much later.


Thank you for the explanation, I believe I understand it now. I had originally interpreted that in a manner to assume that all new features would be tagged with an edition but would be usable on older editions if the compiler supported the feature, but with your explanation I realized that my interpretation of "edition-independent" was off the mark.


Great! Glad to get it sorted. That's a totally reasonable interpretation; we had to debate if that's the way we wanted to do it, or not. In the end, it seemed to mostly add complexity to remove features from people, and that seems like a bad tradeoff.


For me, Rust has made programming fun again. And I find that a langauge has done that maybe twice in my programming career.

I love Rust. It's fun and fast.


I have one gripe about Rust:

The Rust people appear to be actively proud of their documentation, and they appear to be proud of their memory model.

But the documentation of the memory model in the reference manual is seven short paragraphs of waffle, mostly defining various words in terms of other undefined words.

I was mildly surprised at the state of the reference manual when they declared 1.0, and I'm distinctly disappointed that it's still so bad.


The Rust memory model is basically "the C11 memory model, except static checks prevent the unsound parts". We don't have much of a choice, given that we basically pretend to be C at the LLVM IR level and that we want to heavily leverage LLVM's existing optimization passes, which were designed with C in mind.

The "reference" isn't normative, it's just an unprincipled dumping ground for random bits of syntax and semantics and probably should have been deleted years ago, or at least renamed to something with less authoritative weight than "reference" to avoid misleading people as it often does. The Rust devs absolutely do want to thoroughly specify the language someday, though the immediate priority is making sure that Rust survives its first ten years.


> it's just an unprincipled dumping ground

This is not the case, and I don't appreciate you disparaging others' hard work like this.

The reference is accurate, but not complete. Anything inaccurate is a bug, and if they're found, we fix them like any other.


> > it's just an unprincipled dumping ground

> This is not the case, and I don't appreciate you disparaging others' hard work like this.

It is the minimally-charitable interpretation of my statement to assume that I'm trying to disparage the people behind the reference. The document itself is lacking, which is a statement we can make about many nightly/unstable things without disparaging the people working on them; exacerbated in this case because the reference ships as part of the stable documentation, which implies a degree of quality that it does not yet live up to, especially given the high expectations that people have when they of a language reference document such as ECMAScript's or ISO C++.

Starting from the first page of the reference, Notation: https://doc.rust-lang.org/stable/reference/notation.html

The first paragraph links to a section on special Unicode productions. This section defines identifiers in terms of Unicode's XID_start and XID_continue, but this is referring to the unstable non_ascii_idents feature, not anything in the stable language. There is a footnote noting as such, and saying that the situation is expected to improve soon, but this feature gate has existed since before 1.0 and AFAIK no RFC has ever been written to describe this feature, so this footnote gives a false sense of optimism. Furthermore, as per the discussion at https://github.com/rust-lang/rust/issues/28979 , it's very unclear whether or not the stable form of this feature will end up using XID_start or XID_continue. My fix is https://github.com/rust-lang/rust/pull/50790.

In the same section on Special Unicode Productions, it defines the non_null character class as any Unicode character but null, and then the non_eol character class as any non_null character except for newline. Below it then defines a grammar for line comments as two forward-slashes followed by zero or more non_eol characters. But this is incorrect, because Rust does allow null characters in comments: I don't expect that a code example will survive network transmission, but modify the following program by replacing $ with a null to see that it only prints "2", not "1\n2":

    fn main() {
        // test $ println!("1");
        println!("2");
    }
I doubt that this is a bug in rustc, because Go, which like Rust also mandates UTF-8 source files, considers newline to be the only way to terminate a line comment and AFAIK has no issues with accepting nulls. We also allow other nonprinting characters in comments. This same error exists for the classes concerning what is valid in char and string literals. My fix is https://github.com/rust-lang/rust/pull/50791.

Going back to the Notation page, the next paragraph has links to the sections on unary and binary operators. The section on the dereference operator has a typo: "variance" should be "variable". The section on the question mark operator has the typo "errornous". The operator table should have a footnote specifying that integer division rounds toward zero (as opposed to applying a floor function, e.g. http://mathworld.wolfram.com/IntegerDivision.html). (Given the existing footnotes specifying the behavior of the right-shift operator, I assume this is the proper place for this.) Further down, the section on type casts is incomplete; the coercion table misses that non-capturing closures can be cast to function pointers. The section on assignment expressions should note that assignment expressions evaluate to (). Fixes at https://github.com/rust-lang-nursery/reference/pull/337.

The Notations page links to a section on tokens. The Characters and strings table has a column labeled "# sets" that uses notation like "0...", which should have a footnote for clarification. The section on Character escapes refers to the previously-defined term "7-bit character code" as an "8-bit code point escape". In the section on Byte and byte string literals, the grammar definitions for ASCII_FOR_CHAR and ASCII_FOR_STRING exclude forward slashes, when they should exclude backslashes. The section on invalid integer literals says that overflowing literals are invalid, but they're not (this one is arguably something that ought to be changed, and I've opened https://github.com/rust-lang/rfcs/pull/2438 to discuss changing it). The section on valid integer suffixes omits the new 128-bit types. Fixes at https://github.com/rust-lang-nursery/reference/pull/338 for these.

That covers all pages reachable from the first two paragraphs of the reference and notes all the errors that are obvious to me in a single pass. I don't intend this as a disparagement of the documenters--language references are damn hard. There's surely plenty that I've overlooked. The degree of detail is overwhelming and the inherent authority of the word "reference" means that stakes are high. Compared to our other stellar docs the reference is notably lacking, and releasing it alongside them is an outlier from our usual standard of quality. Several large concepts are missing (such as, AFAICT, the type inference algorithm); the section on unsafety may even (if I'm properly interpreting the mood of the members of the unsafe code guidelines working group) be verging on misleadingly dangerous (suffice to say I think the Nomicon should be nightly-only as well (which is also not intended as a disparagement of Gankro's efforts)). The fact that people are still interpreting the reference so authoritatively suggests that more steps could be taken to reduce confusion. At the very least I think it should moved to nightly-only (and likewise remove its mention from www.rust-lang.org)... and maybe also add one of these: http://images.mentalfloss.com/sites/default/files/styles/ins... :)

I apologize for the phrase "unprincipled dumping ground", it was a rash way of saying that the reference is developed in an ad-hoc way where sections are (mostly) added or improved without apparent overarching guidance or large-scale vision, hence all the missing pieces and parts that still date back to 1.0. I also apologize for suggesting that it ought to have been deleted; I still harbor a latent prejudice against the reference for all the years where it existed without anybody noticing that multiplication's precedence was specified as somewhere between addition and subtraction. :)


> It is the minimally-charitable interpretation of my statement to assume that I'm trying to disparage the people behind the reference.

An "unprincipled dumping ground" says something about those who are maintaining it. It's not about charitable interpretations, it's about the contents of what you said.

> I apologize

Thank you. But...

> I still harbor a latent prejudice against the reference

That you do things like this perpetuates the situation you complain about. You're involved with the Rust project; to see you say things like this has even more weight than some random person. Furthermore, to say the things that you've said also demonstrates that you don't actually know what's going on with the reference, making it extra frustrating.

Please reconsider your actions here. They only hurt, not help.

> That covers all pages...

Thank you! All of these things would make great bugs, and I know you know where to file them. Doing so would be a tremendous help, and is exactly what we need to make the reference better. That's what we need more of, not disparaging it and those who work on it in front of thousands of people.


This is because this aspect of Rust is simply not yet defined. There are people working on it. Once it's agreed upon, it will be well-documented.

Outside of the memory model, there's been a few people putting a lot of work into the reference lately; it's been growing a lot. It's a tricky problem.


That's perhaps an excuse for having imperfect documentation. I don't think it's an excuse for it being in the state it's currently in.

Have you looked at that chapter recently? It starts by saying « A Rust program's memory consists of a static set of items and a heap », and literally two sentences later it's talking about «the stack» as if the reader is supposed to know what that is (and as if there's only one stack).


Sure. Please file bugs about stuff like this: https://github.com/rust-lang-nursery/reference/issues/new

That section of the reference is basically inherited from the very old days. Most of the work has been focused on the other parts. Sometimes it takes an outside perspective to notice these kinds of things. I appreciate you bringing it up. Filing a bug means that it won't get lost. If you don't want to, then I'm happy to on your behalf.


Having finally gotten back to rust after one false start (using it for the Synacor Challenge), I'm glad to see it continue to flourish.




Applications are open for YC Winter 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: