Talk:Rust (programming language)/Archive 7

Here are the PR comments that were not addressed. Feel free to pick them up or tick them off if no longer applicable/already fixed. 0xDeadbeef→∞ (talk to me) 11:59, 7 July 2023 (UTC)

• History
  • 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.

    Partly done I've fixed the gap somewhat but we still need some work done here. 0xDeadbeef→∞ (talk to me) 12:52, 16 August 2023 (UTC)

• Syntax and Semantics
  • 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.

    Already done 0xDeadbeef→∞ (talk to me) 10:42, 10 April 2025 (UTC)

  • Put a comment before the last clause of the match statement explaining that the underscore matches any value.

     Done 0xDeadbeef→∞ (talk to me) 00:34, 18 August 2023 (UTC)

  • "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).

     Not done Moot, as that has been reworded. 0xDeadbeef→∞ (talk to me) 11:15, 30 November 2023 (UTC)

  • "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.

    Already done 0xDeadbeef→∞ (talk to me) 10:42, 10 April 2025 (UTC)

  • The types table would be a good place to mention that string slices in Rust are UTF-8 encoded.

    Done (not by me). 0xDeadbeef→∞ (talk to me) 11:15, 30 November 2023 (UTC)

  • The row for references should state that the compiler enforces that the reference is non-null and valid.

     Done in prose

  • "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.

     Done fixed.

  • "Possibly null; safe to dereference" – Similar to my previous comment, this is debatable based on your definition of "safe".

     Not done moot as the table has been removed.

  • "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.

     Done by someone who made that part clearer.

  • "automatically assigns lifetimes to functions if they are trivial" – Unclear whether the antecedent of "they" is "lifetimes" or "functions".

     Not done moot as the sentence was removed.

• Features
  • The paragraph about let in "Types and polymorphism" feels misplaced. Ditto the paragraph about type aliases.

     Not done lost in refactors. dbeef [talk] 06:14, 6 August 2025 (UTC)

  • Some redundancy in the discussion of generics between here and the "Syntax and semantics" section.

     Done deduped

  • "The type system within Rust is based around implementations, traits and structured types." – Vague wording, not clear what this is meant to convey.

     Not done was removed/reworded. dbeef [talk] 06:13, 6 August 2025 (UTC)

  • "Structured types are used to define fields." – Another awkward sentence.

     Not done was removed/reworded. dbeef [talk] 06:13, 6 August 2025 (UTC)

  • "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.

     Done rewritten dbeef [talk] 06:13, 6 August 2025 (UTC)

  • Include an example of a declarative macro.

    Already done dbeef [talk] 06:13, 6 August 2025 (UTC)

  • "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.

     Done expanded that section to be clear and correct.

• Components
  • "Components" is a bit awkward as a section title. It doesn't neatly fit "Versioning system", for instance. Perhaps "Tooling" or "Ecosystem"?

     Done. 0xDeadbeef→∞ (talk to me) 13:09, 7 February 2024 (UTC)

  • Surely you can find an English-language reference for rustup?

     Done. 0xDeadbeef→∞ (talk to me) 13:09, 7 February 2024 (UTC)

  • "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.

    Seems to be Already done. 0xDeadbeef→∞ (talk to me) 13:09, 7 February 2024 (UTC)

• 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?

     Not done as moot as it was removed. 0xDeadbeef→∞ (talk to me) 13:18, 7 February 2024 (UTC)

  • 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.

     Done dbeef [talk] 07:35, 6 August 2025 (UTC)

  • 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.

     Not done. Disagree with the use of benchmarks. Reliable sources' coverage on this is minimal and it doesn't seem appropriate for us to do benchmark stuff to compare languages. (speaking from experience benchmarks don't really measure things outside a specific use case) Comparison to memory safe languages seems good already. (written after this PR) 0xDeadbeef→∞ (talk to me) 13:18, 7 February 2024 (UTC)

• 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.

    Partly done as part of prosefying that section. Exa was removed, Theseus was kept with reliable sources.

  • As of recently, Rust support has landed in the Linux kernel, so this should be updated.

    Already done

  • 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.

     Not done mention of fuchsia was removed from the article

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"?

     Done! 0xDeadbeef→∞ (talk to me) 18:16, 17 July 2024 (UTC)

  • 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.

   Done by me and Sohom Datta. Adoption section was prosefied, and conferences section removed. 0xDeadbeef→∞ (talk to me) 01:30, 23 November 2023 (UTC)

• 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"?

  Already done merged dbeef [talk] 07:35, 6 August 2025 (UTC)

• 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.

   Done mostly rewritten dbeef [talk] 07:35, 6 August 2025 (UTC)

• 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.

Resurrecting it so it gets tracked here (comments by Ovinus):

• A little confused on "1 (Inferred type)" being in the byte row. Aren't integer literals implicitly i32 unless they're too big?

   Not done the table was removed.

• Some stuff on multithreading, and how restricting values to have only one mutable reference at one time prevents data races, etc., since that's what makes Rust powerful for concurrency.
• More on unsafe code and the low-level stuff. The book I have has a fair amount dedicated to signals, interrupts, and all that, and it's good to emphasize that Rust can be used for that. But there's obviously a lot that could be said, so I'm not sure how much is WP:DUE. Also, we should mention that C-style undefined behavior is still a thing, just less pervasive.

   Done by Caleb Stanford dbeef [talk] 04:59, 7 August 2025 (UTC)

• In a similar vein, the fact that a+b where a,b are integers panics on overflow without optimization, and is ignored otherwise, and also the existence of wrapping_add and friends. I think that's a good example of an easily sourcable difference between Rust and C.
• Lack of standardization/formal specification, which is a big difference between Rust and C, and just the fact that Rust is, for most intents and purposes, a monolithic single implementation. Alas, I can't find RS on this topic as I suspect it's a low priority. There is some interesting stuff about formal program verification, e.g.

dbeef [talk] 16:05, 28 June 2025 (UTC)