Wikipedia:Peer review/Rust (programming language)/archive2

Comments from Rublov

Hello 0xDeadbeef. First, some nitpicks and minor issues:

• Lead and infobox
  • "Rust's borrow checker tracks..." – While this use of italics is not forbidden by the MoS, it is uncommon in my experience.

     Done. This use was to suggest that it was an invented phrase.

  • "...the object lifetime and variable scope of all references" – I suggest omitting "variable scope" as tracking the actual object lifetime and not just the variable scope is what distinguishes Rust's borrow checker from traditional compilers.

     Done

  • The reference for the preceding sentence is rather long; could you include a section header or timestamp to identify the specific part that is relevant?

    Were you talking the InfoWorld article or the conference paper? I thought the abstract for the paper provided support for that sentence. 0xDeadbeef→∞ (talk to me) 14:39, 2 December 2022 (UTC)

  • The influences page lists a number of languages other than the ones you've listed, including well-known ones like Swift and Scheme. Any particular reason to pick the ones you did?

    Removed influences in lead.

  • Nitpick: The use of {{cslist}} in the infobox results in a violation of MOS:REFPUNCT.

     Done

  • Per MOS:CITELEAD, inline references may be omitted from the lead, and featured articles often follow this convention; see for instance Armenian genocide. It's not wrong to have them, though.
• History
  • Most of this section is chronological and date-oriented but the paragraph that talks about versions 0.2, 0.3, and 0.4 doesn't have any dates so I don't know when it takes place.

     Done

  • There's a gap of 5 years between the release of Rust 1.0 and the Mozilla layoffs. Is there anything you can say about that time? I think it was an important period for Rust's growth and adoption as a serious programming language.
  • Servo is linked and defined twice in this section.
• Syntax and semantics
  • You might want to mention that statements are terminated with semicolons in Rust.
  • You should have at least a sentence each defining if, while, and for statements; while their meaning is self-evident to anyone that has imperative programming experience, we can't assume the reader does.
  • "Pattern matching is provided using the match keyword" – "Provided" isn't quite the right verb. I would say "The match keyword allows for pattern matching of values" which also has the advantage of not implying that match is the only thing that does pattern matching.

     Done

  • Bit of WP:OVERCITE here. You don't need two references for the fact that // marks a comment, for instance.
  • Put a comment before the last clause of the match statement explaining that the underscore matches any value.
  • "Rust's design was more significantly influenced by functional programming languages." – The reference doesn't fully support this claim. It just says "one significant influence is functional programming", but it doesn't say that the functional influence was more significant than the influence from C and C++ (though that may well be true).
  • "the value of the last expression in the function will be used as the return value" – The way that the factorial example demonstrates this principle is a bit confusing. The last expression in the function is technically the entire if statement/expression, which in turn resolves to the last expression in whichever branch is triggered at runtime, but this two-step process may not be evident to the casual reader. I suggest splitting it into two examples, one showing a simple return like fn double(x: u64) -> u64 { 2 * x } and another demonstrating that if statements can be used as expressions.
  • The types table would be a good place to mention that string slices in Rust are UTF-8 encoded.
  • The row for references should state that the compiler enforces that the reference is non-null and valid.
  • Can you think of a clearer/more realistic example for the never type?
  • "Option values must be handled using syntactic sugar" – "Syntactic sugar" isn't the right term as constructs like match and if let aren't syntactic sugar but rather core parts of the language, but anyway this statement isn't true. I can call .unwrap() on an Option and it will blow up if it is None. You should make it clearer here that while you can still crash your program in Rust by trying to access a null value, unlike in C or C++ this is handled by safely panicking instead of undefined behavior, segfaulting, or worse.
  • "Possibly null; safe to dereference" – Similar to my previous comment, this is debatable based on your definition of "safe".
  • "Lifetimes are a usually implicit part of all reference types in Rust." – The syntax of this sentence is confusing. I suggest splitting it into two parts or two sentences, one about how every reference has a lifetime in Rust and one about how lifetimes usually don't need to be explicitly annotated by the programmer.
  • "automatically assigns lifetimes to functions if they are trivial" – Unclear whether the antecedent of "they" is "lifetimes" or "functions".
• Features
  • The paragraph about let in "Types and polymorphism" feels misplaced. Ditto the paragraph about type aliases.
  • Some redundancy in the discussion of generics between here and the "Syntax and semantics" section.
  • "The type system within Rust is based around implementations, traits and structured types." – Vague wording, not clear what this is meant to convey.
  • "Structured types are used to define fields." – Another awkward sentence.
  • "meaning that the type of all values is known at compile time" – It can't be true that the type of all values is known at compile time, if per the next sentence dynamic dispatch is possible as well as static dispatch.
  • Include an example of a declarative macro.
  • "Rust also has a library, CXX, for calling to or from C++." – Make it clearer that this is just a third-party library and not a part of the Rust language.
• Components
  • "Components" is a bit awkward as a section title. It doesn't neatly fit "Versioning system", for instance. Perhaps "Tooling" or "Ecosystem"?
  • Surely you can find an English-language reference for rustup?
  • "When a project is annotated with the crate-level attribute #![no_std]..." – Explain the difference between the three standard library crates and why no_std would be desirable.
• Performance
  • "Rust aims 'to be as efficient and portable as idiomatic C++, without sacrificing safety'." – This is cited to an individual blog post, which begins with the caveat "Note that this is my take only and not an official decree as to the design of the language by any means." Can you find a better source for this?
  • The discussion of modes is a bit orthogonal to performance. I think it should be introduced in a different section ("Features"?) and only brought up here as it directly relates to using unsafe to write faster code.
  • I know that this is a contentious issue, but it feels odd that this section doesn't directly compare the performance of Rust with C or C++ (or any other language) on benchmarks.
• Adoption
  • My personal opinion is that lists like this should not include entries that aren't blue links, so I would remove Theseus. I would also remove exa as that article seems likely to not meet Wikipedia's notability guidelines.
  • As of recently, Rust support has landed in the Linux kernel, so this should be updated.
  • I don't know if you can find a reliable source for this, but Rust is now the most common language used in Fuchsia (graph). You should find a better citation for this entry anyway as source code is a primary source.
• Community
  • The "Governance teams" subsection should be rewritten to use fewer quotes.
• Miscellaneous
  • Using shortened footnotes with {{sfn}} would make the references easier to read as the Rust Book is cited again and again and the full citation is repeated each time. This style is commonly used in featured articles.
  •  Done

More substantive comments:

• Some omissions from the article that seem notable (not sure if reliable sources can be found for them, though)
  • The ecosystem of third-party crates. This is briefly mentioned in the "Cargo" section but it's a much bigger part of Rust development than, e.g., C/C++ development, and I think it should be expanded.
  • There's a lot of discussion online about the "Rust learning curve"; perhaps a sentence or two about it under "Adoption"?
  • There is not a lot of information in the article about the implementation of the Rust compiler.
• I suggest re-working the "Adoption" section as in my experience list-based sections like this tend to accumulate cruft. Can it be converted into prose that highlights some of the more significant applications and libraries written in Rust? Ditto for the "Conferences" subsection.
• The division of content between the "Syntax and semantics" and "Features" sections is not fully clear. For instance, why does the "Syntax and semantics" discuss generics, but the definition of types with struct and enum is left to "Features"?
• The presentation of material in the "Features" section needs some work. I left some specific comments above, but overall there are lots of places where the organization/flow is not clear.
• Some things to think about in terms of getting this article to featured status: (Disclaimer: I have neither written nor reviewed a featured article. However I have read many recent featured article reviews so I have a general idea of what the expectations are.)
  • The bar for prose quality is higher for featured articles than good articles. I left some copy-editing suggestions, but if you're willing to wait a bit then the Guild of Copy-Editors could perform a more comprehensive copy-edit.
  • I did not perform a full source check but I found a few places where the citation did not fully back the claim in the article. The featured article review process is really strict on source-text integrity and just a few discrepancies can be fatal to a nomination, so make sure that you've thoroughly checked your references.
  • There is not a lot of precedent for featured articles on software engineering topics. C programming language was briefly a featured article in 2006, but the featured article process has changed sufficiently since then that it is probably no longer a useful benchmark. It may be challenging to get this particular article promoted as your first featured article.

Nice work on the article. I made some minor changes to the article myself; feel free to revert or ask me about any of them.

rblv (talk) 14:05, 2 December 2022 (UTC)

Thanks for the review! I will address the feedback when I have time. 0xDeadbeef→∞ (talk to me) 14:39, 2 December 2022 (UTC)

Take your time. I ran into this post recently, which you might be able to incorporate into the article. rblv (talk) 12:35, 7 December 2022 (UTC)

@0xDeadbeef: It has been over a month since the last comment. Are you still looking for feedback, or is this ready to be closed? Z1720 (talk) 02:08, 18 January 2023 (UTC)

@Z1720: I am still finding time to action upon Rublov's feedback, so I don't think more feedback would be needed. If it will clutter the queue to leave this open, then close it. But I want this to be open mostly because I am still working on the article. 0xDeadbeef→∞ (talk to me) 02:14, 18 January 2023 (UTC)

It's OK if you want to keep this open. I just wanted to make sure this wasn't abandoned. Just remember that the longer a PR stays open, the less likely it is to receive comments. Z1720 (talk) 02:28, 18 January 2023 (UTC)

@0xDeadbeef: It has been over a month since the last edit to this PR. Is this ready to close? Z1720 (talk) 18:01, 31 March 2023 (UTC)

thanks for the ping, yes let's close this. 0xDeadbeef→∞ (talk to me) 19:13, 31 March 2023 (UTC)