Talk:Rust (programming language)

Addressing PR comments

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

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

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

Reader comments

Ex-programmer here (C, Smalltalk, Objective-C, Perl, etc) now working in another field. I really appreciated this article and learned a lot about rust from reading it carefully. I may choose to learn the language later. I wanted to point out that there were three spots I had to pause where some edits might be helpful to future readers:

1. The material about lifetimes is quite technical, and the reader must rely heavily on the example to understand what is going on. However, given the rust syntax for this is a bit opaque, the example is hard to follow for a non-rust programmer. For example, I struggled to understand how the 'src lifetime on the struct was relevant to the example. Not sure if I missed something, but I think the action is mostly happening around 'cfg. It may be helpful to add a para more patiently explaining the implications of the statements in the example. As an additional related point, it wasn't clear to me whether these lifetimes have the effect of "extending" the time an otherwise shorter-lived reference is valid, or whether they have the effect of triggering a compile-time error if the constraints expressed in the code cannot be met.

    Done at last. The presentation will need to be improved with some further copyediting, but the bits and pieces should be there. 0xDeadbeef→∞ (talk to me) 04:59, 17 July 2024 (UTC)

2. The material about trait objects is also quite terse. The definition of these objects is covered well, but then it goes to implementation detail. I think the section is missing text on how the appropriate vector element gets used at runtime when a method call occurs. I assume that all the elements of the vector must also express the Display trait, and that some kind of dynamic type-checking occurs to select the desired element. I also wonder if it is possible for the selection to fail if an appropriate type is not available. (If this wondering does not make sense, consider that all I know about rust is from this article, so there may an opportunity regardless to further clarify in the text.)

    Done I've clarified this in the section on trait objects. 0xDeadbeef→∞ (talk to me) 02:20, 15 August 2023 (UTC)

3. The text under the heading Standard Library is quite terse and uses the term 'crate' without elaboration. Although the concept of crate is defined later (perhaps consider reordering sections) there isn't a lot there to explain what is in each standard library crate, or what the benefit of dividing the standard library into three crates is. There is a mention to excluding one of the crates, but I'm not sure what's in there and why I'd want to exclude it. May be helpful to consider what you would like a reader unfamiliar with rust to take from this section, or if it's needed if it falls more into 'how-to' than content 'about' rust.

 Done Caleb Stanford (talk) 16:30, 22 July 2023 (UTC)

Once again, appreciate the article. And as I don't know rust, I will leave it to others to consider changes. -- cmh^TC 13:17, 22 July 2023 (UTC)

This is very helpful feedback, thanks for taking the time to write down your experience reading the article! Caleb Stanford (talk) 16:25, 22 July 2023 (UTC)

possible sources for RustConf

I agree with removing the Rust conferences section (WP:NOTDIR)), but I think RustConf alone deserves mention in the community section as the most widely known community gathering. A bit hard to find secondary sources, I have 1 2 or we could use YouTube sources like 3. Might also be worth asking if we want to mention any of the recent RustFoundation related controversies, which got plenty of coverage. Caleb Stanford (talk) 22:06, 29 November 2023 (UTC)

We should definitely try to cover the Rust foundation controversies if there are good sources available. I am less sure about the reliability of the sources that you bring up. The analytics india mag article's author is an AI enthusiast, and the description of crablang (an unofficial, unmaintained fork) makes me think that it leans toward the unreliable side. 0xDeadbeef→∞ (talk to me) 23:58, 29 November 2023 (UTC)

Closure section

Currently, the closure section throws a parser-specific syntax at the user (and is the only section to that making it somewhat jarring), is there any way we can remove it from the article ? (It seems to be a transclusion of a part of a different article that makes liberal use of the parser syntax, which seems fine). Sohom (talk) 00:42, 11 December 2023 (UTC)

That section isn't placed well. We should to restructure it, by giving it more sources, and some more natural flow. 0xDeadbeef→∞ (talk to me) 14:54, 22 March 2024 (UTC)

Automated memory management

@Wootery: I'm not sure I understand your recent edit -- the lead stated "without requiring the use of automated memory management techniques", so how are you reading this to imply Rust is hands off? It seems to be stating that Rust is hands on. Perhaps I don't know what you mean by "hands off". Thanks, Caleb Stanford (talk) 19:31, 25 January 2024 (UTC)

Perhaps you're right, my thinking was that it seems to imply that Rust offers memory safety while not offering/requiring automatic memory management features, but Rust's borrower checker presumably counts as an automatic memory management feature, in that it isn't done manually by the programmer. For what it's worth, I see the Rust Book uses phrasing closer to what I'm proposing. Anyway, the next sentence clarifies by introducing the borrower checker, so not much hinges on this. Wootery (talk) 21:42, 25 January 2024 (UTC)

I think I can see Wootery's point. Dropping things at the end of a scope, could be considered an "automated memory management technique". And the current sentence could suggest that automated memory management doesn't exist in rust. 0xDeadbeef→∞ (talk to me) 00:20, 26 January 2024 (UTC)

Ah, thanks for clarifying, I see the issue now. I think the point was to suggest that Rust can (but need not) use reference counting, but I think this was very cryptically stated so we should just move that elsewhere. Edited to hopefully clarify, feel free to edit further. Caleb Stanford (talk) 17:36, 26 January 2024 (UTC)

FAC preparation

Alright, after working on the article for some time I am optimistic that we would be able to push this to FA, making it the first ever featured article on a programming language. (which would make it featured eventually on the top left of Wikipedia's main page!!) Before we submit it to WP:FAC, here are some things to prepare:

1. We need to address the comments above, there are a number of comments above in #Addressing PR comments as well as one under #Reader comments that are outstanding and still apply. If anyone has a book about Rust that can help expand the article's technical explanations to something that would be more understandable for a general audience please feel free to contribute! (some comments on the books: I've been trying to source with The Rust Programming Language 2021 edition but I couldn't find an ebook online that has the correct page numbers, if anyone can send me one please let me know, I have ebook copies of Rust for Rustaceans published by No Starch Press, Rust in Action by Tim McNamara, and Programming Rust published by O'Reilly if any wants, as those are good sources)
2. We need to convert all the online sources to book sources if possible. I saw some sources using the documentation for the standard library and preferably we should use books instead.
3. After those issues, we're mostly good to go after a thorough read of the FA criteria, going over all sources in the article and seeing if they actually supported the claim, and reading the article to check its prose.

To people watching this page: Please consider helping out! I'm a bit busy, but if more people contribute it will nudge me to contribute more as well. 0xDeadbeef→∞ (talk to me) 13:40, 7 February 2024 (UTC)

For the comment on lifetimes, I have added some examples that should help illustrate it further. There is another gap between talking about lifetimes in generic definitions and to the example with reading configurations, which could use smaller examples to build the knowledge better. 0xDeadbeef→∞ (talk to me) 15:12, 22 March 2024 (UTC)

Cut OS content

Squizzler (talk · contribs) made some improvements to the OS adoption section (adding r9 and Fuschia) and also removed the following content. I don't mind using the more abridged text as the article is quite long, but posting here in case there are other opinions.

For Linux:

   Support for Rust (along with support for C and Assembly language) was officially added in version 6.1.

And for Windows:

   As of 2023, DWriteCore, a system library for text layout and glyph render, has about 152,000 lines of Rust code and about 96,000 lines of C++ code, and saw a performance increase of 5 to 15 percent in some cases.

Thanks! Caleb Stanford (talk) 16:01, 10 March 2024 (UTC)

References

For Linux, there is a dedicated article Rust for Linux, so only a brief summary is needed here. Android inclusion of Rust is also part of the "Rust for Linux" project.

IMO the use of Rust in Windows is an aspect that should be included in detail here until there is separate article for it. Microsoft is a founding member of the Rust Foundation, but the specifics of the use of Rust in their OS isn't as well known due to the source not being public. Dates are especially important.

I feel the "Adoption" section should be more like a timeline of significant events of Rust being used in significant products / end-user software, and less emphasis on software that havent gained traction yet, e.g. Redox / Fuchsia / COSMIC. etc (apologies to anyone using those at home). John Vandenberg ^(chat) 00:59, 3 September 2024 (UTC)

Controversy Section

@BOBROBMEBOYO: I reverted your edit because it's uncited and felt too brief. I think it's worth mentioning somewhere though. It should be made clear it's about the trademark policy and not Rust's source code license. I feel it should also touch on later events, like the foundation soliciting feedback and updating the policy, and it should include some dates. It might also make sense to put it under the Rust Foundation section. Maybe other editors can chime in. JamenMarz (talk) 06:23, 26 March 2024 (UTC)

It is already in the article, as the last paragraph of the "History" section. Betseg (talk) 11:47, 26 March 2024 (UTC)

Can someone write a Comparison of Rust and C article?

Comparable to the article Comparison of Pascal and C which could be used as an example. I know there is this comparison article for almost every language, but this all languages article is not the same as it only consists of tables and not actual code comparisons like the Pascal vs. C article. 84.140.194.104 (talk) 21:47, 5 April 2024 (UTC)

Hmm. These comparison type articles look like they might violate WP:NOT/WP:NOTHOWTO and WP:OR. Nominating them for deletion would have a chance of succeeding. Not sure they are a good fit for the encyclopedia. Anyway, for that reason, I'm not sure new comparison articles such as Comparison of Rust and C will be written. –Novem Linguae (talk) 22:23, 5 April 2024 (UTC)

I just read the article and it was a great read. It's definitely not a HOWTO or OR. I don't know if NOT applies and why it should, but it would definitely be a great loss if the article were to be removed. It could be substantiated by citing some programming books, but other than that there's nothing to complain about. 84.140.194.104 (talk) 08:01, 6 April 2024 (UTC)

I don't see any benefit in comparing C and Rust. Rust vs C++ is a more common comparison, so would be more valuable and easier to find reliable sources for. Also C++ is evolving at a more similar pace to Rust, with similar objectives in the evolution process. In contrast, while the C standard is being improved, the scope of the evolution is more constrained, and adoption of new editions of C is much slower as C is more often used for its compatibility & stability. John Vandenberg ^(chat) 00:33, 4 September 2024 (UTC)

{{POV}} tag

@LOLHWAT: I'm not getting what you mean by "intro section seems written by a rust contributor to an outside person". As per MOS:LEAD, the lead paragraph of an article provides an overview of the subject, and in this case it provides an overview of the language while highlighting the most significant features (enforcement of memory safety through lifetimes, rapid adoption, etc).

What part of that is non-neutral, in your opinion? 0xDeadbeef→∞ (talk to me) 12:17, 23 April 2024 (UTC)

"Rust is a multi-paradigm, general-purpose programming language that emphasizes performance, type safety, and concurrency. It enforces memory safety—meaning that all references point to valid memory—without a garbage collector. To simultaneously enforce memory safety and prevent data races, its "borrow checker" tracks the object lifetime of all references in a program during compilation. Rust was influenced by ideas from functional programming, including immutability, higher-order functions, and algebraic data types. It is popular for systems programming." The lead section seems to describe rust as a programming language from the perspective of a contributor, and uses words that emphasize its so-called "goodness". There seems to be little mention of its shortcomings. LOLHWAT (talk) 13:13, 23 April 2024 (UTC)

@LOLHWAT: When you describe a programming language, you describe its features. I feel like this is quite a biased take. You don't find Wikipedia covering shortcomings of a programming language right at the lead section (with C++ having a criticism section and Python a mention in a sentence for bloatedness), because it isn't a significant feature of the thing. Unless there is significant coverage of how bad something is, we don't say it is bad. For example, we only can call Phrenology a pseudoscience because nearly all sources describe it that way.

I'm happy to put any criticism of Rust in a section if you could help us find some reliable sources that talk about it. But asking for criticism of a programming language up front, when most sources that discuss the language don't present significant criticism of the language, is just creating WP:FALSEBALANCE. I'm going to revert your addition of the tag, because the justification given here seems insufficient. 0xDeadbeef→∞ (talk to me) 13:40, 23 April 2024 (UTC)

okay LOLHWAT (talk) 15:07, 23 April 2024 (UTC)

Ideas on restructuring this for FA standards

I have some notes on restructuring the parts that provide an overview of the programming language itself, which I'm planning to implement after this comment. However, I noticed two problems in the article:

• The history section, especially for before Rust 1.0, uses some quite poor sources, with archives from the mailing list for the changelogs, and an interview on Graydon Hoare by InfoQ. I think they should be rewritten to use better sources. Some of the details, like when Rust bootstraped itself or when destructors are added, aren't really needed in an encyclopedia article, so probably trim it down. The MIT Technology Review article already provides a good overview, we could just rely on that one only for the pre-1.0 history.
• The adoption section runs into WP:DUE concerns: What made us cover Cloudflare's own blog about them using Rust and not FooCompany's software blog about using Rust? I think we need to significantly trim it down such that only adoptions covered by third party sources (e.g. Ars Technica, ZDNet, etc.) are in the article.

0xDeadbeef→∞ (talk to me) 15:05, 7 July 2024 (UTC)

Sounds good to me. If you want some help identifying better sources, let me know, or maybe list out any other sources that we need to replace. Only thing I probably disagree with is the "when Rust bootstraped itself" date (assuming we can find a better source), that's a rather important event from the perspective of compiler design. Caleb Stanford (talk) 19:09, 7 July 2024 (UTC)

Any help with identifying better sources would be awesome! I don't mind putting the date of Rust building itself as a milestone if there is a good source that mentions it, I'd just assume it isn't lost for an encyclopedia article if there wasn't and we have to remove it (we're writing for a general audience here, after all) 0xDeadbeef→∞ (talk to me) 02:59, 9 July 2024 (UTC)

More action items

These are some notes I took when I went over the article last time. Please feel free to take them and contribute!

• It doesn't help a lot with the types organized into tables. Rewriting them into prose or lists might help readers understand different types better with more explanations attached to each type, and also we could integrate different types that provide different functionalities better.
• The pointers section should distinguish pointers that are built-in to the language and pointers that are provided by the standard library if possible.
• The section on memory management could be merged to the pointers section as a general discussion of how Rust does memory.
• There are parts of discussion on iterators that could be under a general "functional programming features" section, talking about the various methods on iterators.
• Same for closures, that could also get merged into a section on functional programming.
• Variadic macros should not be its own section; it should be merged into other sections on macros as a relatively short note.

0xDeadbeef→∞ (talk to me) 05:55, 18 July 2024 (UTC)

Clarification Needed

"Statements in Rust are separated by semicolons." "Separated" or "ends with" because there is a difference. Glancing at the code, it implies the latter. — Preceding unsigned comment added by 67.241.240.42 (talk) 13:20, 9 September 2024 (UTC)

I agree the latter is closer to correct, and I am not sure the best terminology to use, but .. "its complicated", e.g. fn main() { std::process::exit(1) } is valid. That fn doesnt return anything, so it isnt an "expression" in an implicit "return statement". fn main() { println!("foo") } is also valid, but fn main() { let foo = 10 } is not; it requires the addition of a ";". John Vandenberg ^(chat) 03:58, 10 September 2024 (UTC)

Well, no. Technically, println!("foo") works as a trailing expression because it is an expression that has return type the unit type (), and the main function also implicitly gets that return type, so they are compatible. For let, it is a statement so it must end in a semicolon. 0xDeadbeef→∞ (talk to me) 09:06, 10 September 2024 (UTC)

Right. An accurate description of when `;` is required on the last statement is going to need to explain the unit/zero-tuple type, and that it is often implicit, which oddly I dont see mentioned in the article yet. Did I miss it? John Vandenberg ^(chat) 04:30, 11 September 2024 (UTC)

Yeah, the unit type does need some explanation. 0xDeadbeef→∞ (talk to me) 03:45, 14 September 2024 (UTC)

Developer of Rust?

I wonder who the developer is technically. The Rust Team or Rust Foundation?

I have updated the `developer` field from "Rust Project" to "The Rust Team", since it is said "Maintained by the Rust Team." at the bottom of the official homepage. Charles Dong (talk) 12:10, 26 September 2024 (UTC)

Discussion of lifetime parameters

The discussion of lifetime parameters here is a bit opaque. Would it be possible for someone to expand it? We are given an example, but the syntax isn't unpacked (which precisely is the lifetime parameters, for example?) and it's not at all clear how the lifetime parameter is used in the example function. Does it enable some compiler analysis of the function that is not otherwise computable? If so, what are the results of that analysis, and what would happen if the function did not have a lifetime parameter? There is some discussion of the function as returning lifetime information, too. Once again, the syntax isn't really explained (is that return value a lifetime? It doesn't obviously look like one to a reader new to rust) and without an example, it's not clear what use the caller would make of a returned lifetime parameter. Maybe introduce a code snippet that shows how that return value is used?

I hope this is helpful feedback; if I knew enough to answer these questions, I would try to do this myself, but I'm afraid I don't. Rpgoldman (talk) 14:57, 29 October 2024 (UTC)

Thanks for bringing this up. I took an initial stab at editing it! Let me know if it's clearer or if we can make further edits. Caleb Stanford (talk) 17:53, 29 October 2024 (UTC)

Pre-1.0 History

Secondary.. sources.. that are reliable.. It shouldn't be that hard to find sources covering development before 1.0, right? right?

cc @Caleb Stanford: Thanks a lot for stepping up to add content in the history section. The talk at Applicative 2016 is a good WP:PRIMARY source we can use. For even better verifiability, we should probably consider adding timestamps for specific claims. As for written sources on Rust's early history (and some extra stuff), I dug some of these with some searches:

• Mozilla releases Rust 0.1, the language that will eventually usurp Firefox's C++, Extremetech, 2012-01-24
• Samsung joins Mozilla's quest for Rust, CNET, 2013-04-03
• Samsung teams up with Mozilla to build browser engine for multicore machines, Ars Technica, 2013-04-03
• Samsung and Mozilla join forces to develop next-generation Android web browser, Extremetech, 2013-04-03
• Mozilla Imagines a Brave New Multi-Core Firefox With 'Servo', WIRED, 2013-04-05
• Mozilla-backed Rust language stabilizes at version 1.0, Ars Technica, 2015-05-16
• Rust 1.0, the programming language behind Mozilla's new Web engine Servo, is released, Extremetech, 2015-05-20
• Facebook is writing a Mercurial server in Rust. This is not a drill, The Register, 2016-10-18

The coverage on Rust itself is still quite limited. But I think that is okay. The technical details of the language before 1.0 wasn't of interest to the news people, nor the academia people, so we shouldn't cover it either. This is an encyclopedic article that is supposed to provide general information on the language, so extensively using a primary source to cover some technical history feels icky. I feel like we should just cut down the technical details (see also WP:NOTCHANGELOG) and make more general statements about the development. (that either directly comes from the talk source itself or comes from a secondary source) 0xDeadbeef→∞ (talk to me) 06:29, 1 November 2024 (UTC)

Will spend some more time going at it if I get some free time this weekend.. before then, excuse my backseat commentary ^^' 0xDeadbeef→∞ (talk to me) 06:30, 1 November 2024 (UTC)

Thanks! 😅 I totally agree with the sentiment. Some specific points below:

> As for written sources on Rust's early history (and some extra stuff), I dug some of these with some searches:

This is amazing and super helpful, thank you! Honestly during the writing of this I was... severely in want of more sources.

> The technical details of the language before 1.0 wasn't of interest to the news people...

Agree! I guess I should clarify:

• what I think is of general interest: (1) the non-technical details including how Rust came to be, how it was funded; (2) who was involved (major contributors and individuals) (3) why and how it grew in popularity (4) important conceptual changes over the years (like the removal of the garbage collector and function purity) that are relevant to Rust today and to its historical development. Many of these details were completely missing from the earlier draft (and much of it still incomplete! For example the article prior to now doesn't even name the core team or initial developers of the language post-Graydon years).
• what I think should be skipped: (5) syntactic changes or examples of old syntax; (6) changelog content (like first para. of Evolution, I left it bc it was previously drafted, but I actually think it should be condensed to maybe at most a sentence or two).

> The talk at Applicative 2016 is a good WP:PRIMARY source we can use

Are you absolutely sure that it's primary? Klabnik was not involved prior to 0.1 (first 2 subsections). I understood his view to be secondary on that basis. Of course, we should interpret the video as WP:PRIMARY post-involvement after he was added to the core team (which I am not sure of the exact date but we can dig it up).

Would that also make Klabnik & Nichols primary? which could be...a bit of a serious issue, if that's really what you are contending and I'm not misunderstanding or mistaken.

LMK what you think, I suspect we are close to a consensus here if we can agree on the status of Klabnik's involvement pre-0.1.

Caleb Stanford (talk) 19:08, 1 November 2024 (UTC)

P.S. Btw, why are we allowing all these mail.mozilla.org links but not GitHub source history? Because it's not archived? I'm not clear on the distinction. Thanks! Caleb Stanford (talk) 23:22, 1 November 2024 (UTC)

We should be removing those. I was only removing one because I got a bit lazy.. Sorry! 0xDeadbeef→∞ (talk to me) 03:13, 2 November 2024 (UTC)

Thanks! That makes much more sense :-) Caleb Stanford (talk) 17:50, 3 November 2024 (UTC) Agreed on WP:IS and reasoning below. Thanks for clarifying. Caleb Stanford (talk) 17:50, 3 November 2024 (UTC)

I'm not completely sure. I think calling them (the talk and the book) secondary is fine, though there's also consideration of WP:IS. And maybe perhaps Klabnik is not considered a third-party, we could still consider the source as independent? Wikipedia:Party and person#Doesn't "third party" mean "independent"?

As for which parts are general interest, I think parts of (4) might be debatable. For example, I think we can cite the fact that Samsung contributed to Rust 0.6 which added in ARM support based on some of the sources I listed, but the things about typestates and pure functions? Might not be necessary. 0xDeadbeef→∞ (talk to me) 03:37, 2 November 2024 (UTC)

I'll argue for the inclusion of typestates and pure functions. About typestates, well, I don't personally care much at all about them but (per the sources I've read) lots of people talk about them as a major part of the language's history, they seemed to impact the conceptual design of Rust from the beginning. So while I personally don't care I'm not comfortable overriding the sources. Removing pure functions OTOH was (WP:OR warning) possibly the biggest mistake in the language's history. (end of WP:OR) As to the relevance it has to do with the claims about the relation to functional programming and the influence of functional programming on the language (which is of general interest) and which we discuss in several places. Caleb Stanford (talk) 18:01, 3 November 2024 (UTC)

Are there reliable sources that talk about typestates as a major part of the language's history?

I do understand why you consider removing pure functions an important event, but so far your reasoning probably doesn't fit the main way we deal with editorial decisions. If there are reliable sources that talk about the removal of pure functions as a key milestone, then great, let's write that into the article. If there are not, let's not be sad that it doesn't make it. 0xDeadbeef→∞ (talk to me) 09:16, 4 November 2024 (UTC)

P.P.S. I've restored the RustConf 2022 source, but LMK if you disagree. I am also not clear on why we can't use a limited number of primary sources "to make straightforward, descriptive statements of facts that can be verified by any educated person with access to the primary source but without further, specialized knowledge" (WP:PRIMARY) which is exactly what I'm doing -- there's no interpretation going on here. Just trying to get our own facts straight. Whether you consider it of general interest is a separate question. Thanks! Caleb Stanford (talk) 23:50, 1 November 2024 (UTC)

The RustConf 2022 source appears to only support the statement within the footnote, but not the main content (when the compiler successfully bootstrapped itself) 0xDeadbeef→∞ (talk to me) 03:17, 2 November 2024 (UTC)

Ah you are right about that. I thought about it a bit and I think we should just remove the claim. But WP:ABOUTSELF does not apply here right @Sohom Datta:? Confused about the message (not the revert itself). That's a secondary source. Thanks! Caleb Stanford (talk) 17:52, 3 November 2024 (UTC)

Misleading claim

"Rust also uses a feature known as trait objects to accomplish dynamic dispatch (also known as duck typing)" I think this is highly misleading. Duck typing and dynamic dispatch are two different things. Duck typing is the principle that *at runtime*, an object `o` can be typed as `T`, if `o` implements all relevant methods of `T` (e.g. as Python does it). Dynamic dispatch does not do that; If I have two traits `T1` and `T2` with the same method signatures, I *still* can not dynamically use an `o:dyn T1` as a `dyn T2` - they are two fundamentally different types. Duck typing would allow for that.

(Please someone correct me if I'm wrong) 92.215.116.17 (talk) 15:35, 5 December 2024 (UTC)

I'll take a look at this once I have a bit of time. Other editors, feel free to confirm and correct. (Also, IP, if you want to use italics or inline code, WP:WIKITEXT provides a great reference for how to do all these things with MediaWiki markup.) /home/gracen/ (yell at me here) 15:42, 5 December 2024 (UTC)

The source is a little bit more precise about this: "This concept—of being concerned only with the messages a value responds to rather than the value’s concrete type—is similar to the concept of duck typing." I will take a stab at fixing the wording. FWIW I agree with your example of why they are different, OTOH I think this difference is rather immaterial. It's quite easy to create a trait T3 which provides the shared method signatures and impl<T: T1> T3 for T, impl<T: T2> T3 for T. It would be accurate to say that overall Rust allows for duck typing with a bit more syntax to accomplish it and make the requirements explicit. Caleb Stanford (talk) 16:15, 5 December 2024 (UTC)

It's true that one can externalize the shared methods into a common super trait, yes. I still think the distinction matters though, especially if we consider wikipedia an educational resource. Using duck typing, I can turn a cat into a dog, if both are just animals that make_a_noise(). Using dynamic dispatch, a cat is a cat and remains a cat. I can consider it an animal, but I can never turn it into a dog ;) 92.215.116.17 (talk) 16:30, 5 December 2024 (UTC)

Agreed! :) LMK if you think the latest edit is clearer. Caleb Stanford (talk) 16:40, 5 December 2024 (UTC)

much better, yes :) Thank you 92.215.116.17 (talk) 16:42, 5 December 2024 (UTC)

I made some more changes and added an explanatory footnote. What do you two think? /home/gracen/ (yell at me here) 16:57, 5 December 2024 (UTC)

Good, probably even better to mention interfaces first: "Rust also uses a feature known as trait objects to accomplish dynamic dispatch, which is similar to Java's interfaces and can allow for similar program logic to duck typed languages like Python." It is also likely possible to condense and/or omit the footnote. Caleb Stanford (talk) 17:44, 5 December 2024 (UTC)

I'm pretty busy at the moment, so feel free to go ahead and make these changes yourself :)

/home/gracen/ (yell at me here) 17:53, 5 December 2024 (UTC)

@Caleb Stanford: After taking a look at what you wrote ([1]) and the surrounding text, I've decided to make significant changes to avoid WP:SYNTH (i.e. my reference to Java). I like your decision to remove the footnote, that definitely makes it more accessible to less experienced readers. What are your thoughts? /home/gracen/ (yell at me here) 21:40, 5 December 2024 (UTC)

It does look like an improvement to me. Thanks! Caleb Stanford (talk) 17:35, 6 December 2024 (UTC)