# Talk:Rust (programming language)

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.

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)

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

Is for value in 4..=10 a typo at the = character? If not, can it be explained better in the article or a simpler example used?  Stepho  talk  06:00, 20 December 2024 (UTC)

It's not a typo. Should be clearer now, thank you for the suggestion. Caleb Stanford (talk) 17:49, 7 January 2025 (UTC)

Why does it say that Rust first appeared May 15, 2015 in the info box? As far as I can tell that's the date version 1.0 released, but I don't think it makes sense to say that's the day it first appeared - lots of software was written in Rust before 2015. For comparison, Go released version 1.0 in 2012, but the info box says it first appeared in 2009. Sheddow (talk) 18:58, 5 January 2025 (UTC)

I think that's a good point! 0.1 is the first public release (January 2012), so I'll change it to that for now. I'm not sure what the general convention is here. Caleb Stanford (talk) 17:47, 7 January 2025 (UTC)

I'm reading through this article and considering nominating it as a featured article (this would be my first nomination, so I'd likely be going through it with a mentor). I'm taking notes at User:Gracen/Notes/Rust (programming language) and any additions and feedback are welcome. I'll probably use this topic as a place for discussion before bringing it to WP:PR and WP:FAC after. Again, input is welcome! /home/gracen/ (they/them) 19:43, 5 February 2025 (UTC)

@Caleb Stanford, @0xDeadbeef: apologies for the ping, but as the main authors of this article I'm curious what your thoughts are. /home/gracen/ (they/them) 21:39, 7 February 2025 (UTC)
Thanks for initiating the discussion. Overall, I think this is a great idea & happy to help push this to submission! I looked at the list of changes you compiled so far and I think these would be great improvements. I don't personally have experience with WP:FAC either, so I am not sure I can judge whether it is ready but welcome the opportunity to improve the article further, perhaps 0xDeadbeef can advise better. Thanks! Caleb Stanford (talk) 23:15, 7 February 2025 (UTC)
Thanks for leaving this message. Coincidentally, I have some spare time in my hands, so I will need to take some time to implement the changes that I have envisioned for this article.
My top priority for this right now is improving the syntax and features section. Re: Check with other programming language articles, a lot of this reads like a tutorial. It likely needs a complete rework - This is probably the best article we have on a modern programming language. AFAIK this is the only programming language article that still has GA status. So no, trying to follow other languages' styles won't work for us.
But here's my initial thoughts on that comment: We're writing an encyclopedic entry for a programming language, so it makes sense that we are providing an overview of the language. It makes sense to use examples to illustrate parts of the language, although we need to nail down exactly what we cover, as the current version lacks certain details (where are closures?) and may have too much details in other cases. I'd like to hear your thoughts on this, but I don't think this needs a complete rewrite. It just needs some more careful reorganization. 0xDeadbeef→∞ (talk to me) 04:15, 8 February 2025 (UTC)
I'll get back to this in more detail once I get to a keyboard rather than a phone, but I appreciate the thoughts! To be honest, the main reason I felt it was too close to a tutorial was the interjection of stuff like "this example uses a comment, this is what a comment does", but on second thought that was more than likely my experience with Rust showing and I'll read through it again later with a (hopefully) more reader-oriented perspective. I still think stuff like that could be reworded and improved, but you're right that a complete rework is very likely too far.
Also (somewhat in response to the fact that this might be the only programming language GA), just wanted to point out that part of my reason for wanting to see this as FA is because I was disappointed to see that C (programming language) was a former FA, and it would be kinda neat to see my favorite language set as the gold standard for these kind of articles (and hopefully that would encourage more redevelopment of articles like C). /home/gracen/ (they/them) 10:26, 8 February 2025 (UTC)
yeah. it will be hard. C was demoted from FA 19 years ago, and to set a new editorial standard for articles would be nice. 0xDeadbeef→∞ (talk to me) 12:24, 8 February 2025 (UTC)
I usually take a wikibreak over the weekends, so apologies for the two day delay in response!First of all, after reading through the syntax and features section again, I'd like to reiterate that I completely agree that it is of encyclopedic value; I was completely off base with my initial claim that it needed a complete rework. I'm currently reading through more thoroughly and making a couple minor edits, leaving major edits for later on my notes page. I'll also read through the Rust book again and take some notes to see what's missing from this article.Secondly, I'm curious about your thoughts on my plans to expand the ecosystem section. Do you think it's necessary? Would you rather reduce it instead? I haven't gone source hunting yet, so I'm not sure whether or not there is actually more to include, but I just wanted a more experienced editor's thoughts. /home/gracen/ (they/them) 20:52, 10 February 2025 (UTC)
Thanks for taking your time to reread this. I'm not completely sure we need a lot of expansion for the ecosystem section. If we do have sources for it then we can go ahead and expand it. I'm curious about what you'd suggest adding. 0xDeadbeef→∞ (talk to me) 08:18, 14 February 2025 (UTC)
 Firstly, I'd like to apologize for the major delay; I came down with strep and in combination with other off-wiki stuff that made it hard to focus on editing. However, I'm feeling better now and I'd like to jump back into this!  I'd agree with you that the ecosystem section doesn't need significant expansion, it just feels to me like some sections could have maybe a couple sentences to a paragraph more information on the relevant tool. For instance, the section on Clippy only has 2 sentences, and one of them is just explaining what a linter is! I want to add a sentence or two more on exactly what sorts of lints it provides and maybe some Rust-specific features. I was also thinking of adding a bit more detail to rustfmt, giving an overview of its style and highlighting its opinionated nature.  I'm probably going to give the article one more thorough read-through before bringing it to peer review, so please let me know about any concerns you have. Sorry again for the delay, and thanks again for the advice! Gracen (they/them) 18:24, 5 March 2025 (UTC)

Info about tuples was in the article but after the primitive types table was turned into paragraphs, it disappeared. I think tuples are a very important feature that should be mentioned, but I couldn't fit it myself. Can one of the contributors try to fit it in somehow? Betseg (talk) 21:46, 15 February 2025 (UTC)

are you out of your mind? What's that got to do with a programming language??? 87.122.21.128 (talk) 10:09, 9 May 2025 (UTC)

Those numbers are statistically meaningless. Are they lower or higher than the equivalent figures of the general population? Is the general population to compare them against mostly western or includes China, Africa and Russia? Is the link due to the nature of the language or the nature of the community? Is the community friendly due to the nature of the language or due to the nature of those that begun the project. Does the community actively encourage these type of people specifically or is it just a case of general friendliness?  Stepho  talk  10:49, 9 May 2025 (UTC)
Right now this statistic is slightly borderlining on WP:OR, not because the percentage was calculated by hand (that wouldn't violate WP:V), but because I'd say using a primary source for this might not be really suitable.
As someone with involvement in the community, Rust being welcoming to queer people is not news to me. But I think a small mention would be fine (another question, if we were to use those survey results, why leave out the percent of people that are neurodivergent?), since the MIT Technology Review article mentions it: The community embraced it, and that, longtime Rust community members say, drew queer and trans coders to get involved in Rust in higher proportions than you’d find with other languages.
cc @Caleb Stanford who added this sentence. I'm kind of leaning towards removing the demographic statistic unless some secondary source decides to analyze it. This could take a while, of course. One analysis of demographics I encountered in the wild was done on Linux kernel contributors in the book The Success of Open Source by Steven Weber.
By the way, will someone please publish a journal article about programming communities and their intersection to minority social groups (e.g. neurodivergent, queer)? This seems like a gold mine of interesting and researchable stuff (perhaps the academia's economic model has not incentivized this kind of research yet) 0xDeadbeef→∞ (talk to me) 13:17, 9 May 2025 (UTC)
+1 to @0xDeadbeef and I have removed the demographic data on that basis. I also rephrased the usage of the Nature article to be more in line with the source. Caleb Stanford (talk) 15:36, 9 May 2025 (UTC)

I don't think this is necessary and helpful, because

it isn't place at an appropriate location. Doing it right after hello world seems too surprising.
An encyclopedic article about the programming language is different from a reference about the language. There are things that the article should intentionally omit as it only serves as a summary of the subject (see WP:IINFO). A high level summary does not need to contain all reserved keywords.
dbeef [talk] 05:52, 12 June 2025 (UTC)

1. OK, then move it further down. I only put it at the top because I argue keywords are an extremely vital/fundamental part of a language.
2. The addition of the keyword list does not turn the section in to a reference page. It is at the very least useful on creating an illustration of the language. That being said it does not turn it into non-encyclopaedic content (extensively detailed reference) either as it only provides the list at a high level overview, not explicitly giving the meaning of each.  2605:8D80:13E8:3B9B:EDA4:2C03:4ADB:4AE6 (talk) 10:16, 12 June 2025 (UTC)
We already describe many keywords in the article content itself. There's no need for a separate list. dbeef [talk] 15:59, 12 June 2025 (UTC)
Again, I don't see how the inclusion of the list detracts from the high-level overview nature of the page, especially when there does not exist a Rust syntax page yet like C syntax, C++ syntax, C Sharp syntax, and Java syntax. Just because "many keywords are described" in the article does not mean that including a list of all keywords somehow diminishes the simplicity of the article, especially if the list does not enumerate the functionality of every single keyword in the list, but rather only lists them for reference. 24.50.56.74 (talk) 16:54, 20 June 2025 (UTC)
I think it is too long to be included in the main article. A separate article may be fine but I'm aiming for this article to become WP:FA some time in the future.
I don't think including a list of keywords in the main article in the language is necessary, that's a technical detail that won't be of benefit to our primary audience, who wants what is Rust? answered (which won't need a list of keywords, at least IMO) dbeef [talk] 12:09, 21 June 2025 (UTC)
Well, I would appreciate if you could create a page like that. I am an IP editor so obviously I don't have access to page creation. 24.50.56.74 (talk) 17:11, 23 June 2025 (UTC)
You can submit an article through Articles for creation! FYI. Caleb Stanford (talk) 06:47, 24 June 2025 (UTC)
I ended up creating an article here. As it turns out, that page already exists, so I'm going to have a talk section on potentially moving the entire section to that page. 24.50.56.74 (talk) 20:43, 24 June 2025 (UTC)

The syntax and features section of the page is very long and unwieldy, especially for a page that is a high level introduction to a programming language for a reader that may not necessarily have computer programming knowledge. Therefore I propose that the entire section be moved to the page Rust syntax (which previously was just a redirect to this same section) and in its place the existing syntax and features section be trimmed down to only key points or basics about the language that illustrate its syntax sufficiently. 24.50.56.74 (talk) 20:49, 24 June 2025 (UTC)

I'm going to go ahead and make the changes, and if there are any objections they should come here. 24.50.56.74 (talk) 13:39, 25 June 2025 (UTC)
now its all messed up because some of these things you moved over are not syntax at all. I do think the syntax and features section could be trimmed down where possible - but having the stuff over here is better than having nothing.
If you aren't willing to write the summary that points out key language features/details, then don't move it.
I don't think this article should be aimed at beginners with no computer knowledge. We can have something akin to Introduction to general relativity vs general relativity when someone is willing to write Introduction to Rust. dbeef [talk] 17:00, 25 June 2025 (UTC)
and, like, I think we at present do a really good job of summarizing the language. A programming language is a lot, and there's a lot out there that we currently don't cover.
If you actually give the section a read it actually feels quick, at least to me.
I had plans to trim the "Standard library" section, as well as the "Pointers" section. I've been thinking and brainstorming ways to improve the structure of the article a lot. I don't think removing it wholesale and moving it to a separate article is the way here. dbeef [talk] 17:17, 25 June 2025 (UTC)
You are welcome to disagree or criticize my changes, but I am displeased that it took a day for any response to this section and occurred only after I had made changes, especially when you had already seen the creation of the article and made a comment on it in the edit history, but made no comment here. Also, expecting the responsibility to "write the summary that points out key language features/details" to fall completely on me, given the way you speak of the article, you apparently seem more than familiar with contributing to the article's content, feels a bit unfair. I make this point in particular because when compared to other Wikipedia articles about programming languages, such as those of C++, Java, and C#, the syntax section is extremely brief and points to a main article that elaborates all the intricacies of the programming language syntax. There is really no good reason why the "Syntax and features" section of the Rust page is as obscenely long as it is (it is already longer than several independent Wikipedia articles), especially when there is already a dedicated page for that (which always existed, but was for some reason a redirect, the reason this was the case eludes me even now). There doesn't need to be a list of types and objects in the Rust standard library in the main page about the Rust programming language, for instance, nor does there need to be a section explaining what pattern matching is just because it is a feature of the language or even explaining what if/else, for, while, and loop blocks are, considering these are typically core features of basically every programming language. If there is anything that would particularly belong in the main article, it's perhaps the section on the borrow checker and the ownership/reference models that the language uses (as these are of particular interest to the language). But most things in the article have no good reason to be there when a dedicated article for the topic exists already - the page is gargantuan as is because of that section alone.
Anyway, if you want to know what I would have proposed instead ("the summary that points out key language features/details" that you described), I would trim the entire section and keep only the "Hello world" section and the section on ownership and memory safety, as for many readers these are the particular distinguishing features about Rust (go to any media discussion about the language and you will often hear discourse on Rust's memory safety model and how it compares with C++, or what causes the growing interest in the language). The article would be improved in structure if for someone completely new to programming wouldn't be overwhelmed by a massive section on all the fundamental concepts in the language, even if it doesn't literally enumerate every feature of the language, because that would be absurd. Even this limited subset of features is still very long, and better suited for a separate page for someone genuinely interested in the features/syntax of the language. Not every reader is seeking the intricacies and specific details and implementations of the features in the language.
You also say "I don't think this article should be aimed at beginners with no computer knowledge. We can have something akin to Introduction to general relativity vs general relativity when someone is willing to write Introduction to Rust." But that's just pointlessly unwieldy. The comparison you make isn't appropriate because Wikipedia isn't a tutorial page, and it's not Wikipedia's responsibility (or purpose) to guide people how to learn a programming language. Making the main Wikipedia article be targeted only for experienced users of the language is just needlessly esoteric, and you are basically telling readers without programming knowledge to "go learn about the topic elsewhere", which is not the purpose of Wikipedia. The point is that there is already a dedicated page for the syntax of the language, and it would make more sense to use it for its intended purpose. The Electromagnetism page doesn't inundate readers with all the formulae and derivations of Maxwell's equations when a Wikipedia page for that exists already, nor does the page for Algebra contain a proof of the Abel–Ruffini theorem, because a page for it exists already. 24.50.56.74 (talk) 17:56, 25 June 2025 (UTC)
A day to respond is not unreasonable at all. We are all working on volunteer time here! I also agree with dbeef that the current version of the article is better.
BTW, I do recommend you consider getting an account. It's not required, but it's a gesture of good faith, and it helps other editors identify you and your contributions in talk page discussions. Caleb Stanford (talk) 21:24, 25 June 2025 (UTC)
Could someone explain the justification for having the "Syntax and features" section being as long as it is? I'm not sure if I'm just insane for seeing things the way I do, because no matter how hard I try I can't possibly come to a good reason why a Wikipedia article about a non-specialised subject (a programming language, not a specific feature or subset of features of a programming language) "should [not] be aimed at beginners with no computer knowledge", let alone should be as long as it is. 24.50.56.74 (talk) 23:23, 25 June 2025 (UTC)
If you're talking about prose size, the word count of Rust (excluding code examples) is smaller than 6,000 in WP:SIZERULE.
See also WP:HASTE. Anyways, to respond:
given the way you speak of the article, you apparently seem more than familiar with contributing to the article's content, feels a bit unfair - yes, that's why I think doing a wholesale cut and paste move there is not good. We at least have to agree on which parts to cut and which parts should not be cut.
when compared to other Wikipedia articles about programming languages, such as those of C++, Java, and C#, the syntax section is extremely brief and points to a main article that elaborates all the intricacies of the programming language syntax - in terms of article quality, Rust is probably the best article we have on a programming language. You can see this at the top banner of this page. C++ was a former good article. Java was a former featured article (and did not pass GA subsequently), C# has no development and remains at B class. You probably assumed that the other articles follow better practices, but not really. Rust is the best article we have (in terms of article quality) of a programming language. What we do here sets examples for other programming language articles to follow.
The problem here is that I've made it so that the syntax and the features are merged together to a single section - because it's easier and less confusing to discuss the two together. To have a separate article exclusively talking about Rust syntax and features would make the main article hollow: why wouldn't someone look for a good summary (with appropriate amount of details about) the syntax and features of the language when they look at the main article? The other issue would be the use of and in the title: see WP:AND. Those are the reasons why I think these should be kept.
The other thing is that our description of Rust allows readers to differentiate Rust from the language they are using. Variables - immutable by default, with type inference, different to Java/C/C++/Python, Block expressions - very different to other languages. If expressions don't use parentheses, and can be a value expression - different to many other languages. For loops work with iterators and range syntax - compare this to language of your choice. Pattern matching - not every language has this. And we can go on and on. The thing is the syntax and features section does a good job of introducing the language to people with background in other programming languages but are perhaps introduced to Rust for the first time.
The article would be improved in structure if for someone completely new to programming wouldn't be overwhelmed by a massive section on all the fundamental concepts in the language - but we're not aimed at people completely new to programming. There's no way to write an adequate summary of Rust without using jargons and technical terms - that's necessary because Rust is a programming language. But what we can do is create a separate article titled Introduction to Rust that does aim at people completely new to programming. See MOS:JARGON on the guidance.
Even this limited subset of features is still very long - I don't think so? It's not that hard to follow and read through the code snippets. And it feels quick to me. It being longer than other articles is because we're better.
Not every reader is seeking the intricacies and specific details and implementations of the features in the language. But we're not talking about intricacies? Give me evidence for why you think so. I think this is a general summary?
Wikipedia isn't a tutorial page, and it's not Wikipedia's responsibility (or purpose) to guide people how to learn a programming language - yes, but we can have two articles that target audiences of different technical levels. Why not?
you are basically telling readers without programming knowledge to "go learn about the topic elsewhere", which is not the purpose of Wikipedia - until someone creates and writes a good article on Introduction to Rust, yeah probably? There's no good beginner friendly introduction of the features anywhere here and moving the section to a different article is orthogonal to this other goal. dbeef [talk] 05:03, 26 June 2025 (UTC)
We at least have to agree on which parts to cut and which parts should not be cut./The other thing is that our description of Rust allows readers to differentiate Rust from the language they are using. - Fair enough. I instead propose that existing sections be trimmed rather than moved wholesale to the other page, enough that what distinguishes the language can still be communicated without having the section be as long as it is.
but we're not aimed at people completely new to programming. There's no way to write an adequate summary of Rust without using jargons and technical terms - that's necessary because Rust is a programming language. - Apologies for the poor choice of words. I'm not asking to completely preclude any inclusion of any snippets of Rust code, but I think it at least ought to be in a way that is digestible to non-programmers, seeing as the page is about a programming language. Lots of people without programming knowledge may browse a page about a programming language just to read about it, the same way people without mathematics education might incidentally stumble on the Complex analysis page. It obviously can and should use snippets of the language, but not to excess, especially when a specialized page about the subject can (and does) exist.
The problem here is that I've made it so that the syntax and the features are merged together to a single section - I understand, but the language features of Rust (and I am not referring to the standard library - of course, there are Wikipedia pages for the C, C++, C#, and Java standard libraries and I think it would be good to create a Rust standard library page too, but that's a discussion for another time) are directly related to the syntax of the language. Rust does offer unique features that other languages do not, and it would be expected of the Wikipedia page to elaborate on these, but that doesn't mean they are distinct from the syntax (to put it simply, the pattern matching features have a syntax that could be described in in the Rust syntax section, the usage of Option<T> and Result<T, E> instead of Exception types is also a feature that distinguishes the language's use and has an associated syntax for handling said errors, etc.). This is why I don't think the Rust syntax page need not include information on the same features described here.
yeah probably? There's no good beginner friendly introduction of the features anywhere here - Apologies for another poor choice of words. I'm not asking to turn the page into a tutorial or "Introduction to Rust" page. It's reasonable to expect readers to understand what if/else/for/while blocks are, etc. But it shouldn't be in such a way that overwhelms a reader with such an extensive page (even if it is just a subset of the fundamentally distinguishing features of the language) - this is why I think it should be trimmed so that intricacies go to the Rust syntax page whereas the high-level overview of syntax remain here. 24.50.56.74 (talk) 13:41, 26 June 2025 (UTC)
Since you also agree that trimming it down could be a sensible path forward, could you point to places in which we should trim it down? Again it is hard to know what you mean by overwhelming the readers when you don't provide actual specific examples. dbeef [talk] 14:18, 26 June 2025 (UTC)
Sorry for the delay in response.
I noticed that you have made an effort to trim parts of the article, such as the pointers and standard library types, which is good. In reconsideration, I don't think the problem is necessary the length per se, but rather the scope of that section in distinguishing Rust between other languages. In particular, I personally think the section on types is a bit long and not particularly of interest, when you consider that these are common features in many languages. Primitive types and compound types, while fundamental, are perhaps too fundamental to warrant having to explain in detail (yes, this is a shift from my previous view of the article being too opaque for readers without programming experience, though that's not the reason I bring it up). I also personally think the pointers section could be a subsection of types instead, and even the "user-defined types" could be moved there, while the standard library section could be made its own entire section separate from the syntax and features section (the Rust standard library is a topic of particular interest). I also think more can be done discussing unsafe code and undefined behaviour, which are also of particular interest, and particularly distinguish the language as the way Rust handles unsafe code/undefined behaviour is different from the way C and C++ handle it, etc. 24.50.56.74 (talk) 13:49, 30 June 2025 (UTC)

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. [2]
dbeef [talk] 16:05, 28 June 2025 (UTC)

I think type annotations should be included in declarations in this page, and we should be aware of the fact that not all readers are necessarily familiar with all types in Rust, and being as explicit as possible is helpful for readers that are not familiar with the language. User:Dbeef, you argue that adding type annotations increases verbosity and does not accurately represent what Rust code typically looks like, but I don't think this is an appropriate assessment, as the inclusion of a type annotation is not "super verbose" in such a way that it detracts from anything at hand in the code snippet, and while code that is written in Rust may just be written raw without type annotations, often language servers will give the type annotation for that symbol anyway, and just writing the declaration without any type annotation just omits the type information from the reader entirely. 24.50.56.74 (talk) 13:59, 20 August 2025 (UTC)

Writing to agree with User:Dbeef here. It's more idiomatic to omit the types - though it would be helpful to include them on a few selected examples (such as the first few examples, or any examples with a new type) before explaining that they are inferred. Caleb Stanford (talk) 14:14, 20 August 2025 (UTC)
I think it is important to convey as much information to the reader as possible without detracting from the page content or topic of interest, and it is still important to note that not all readers are familiar with the types of all symbols in Rust (they may not be aware what let foo = 10; will be deduced into). Also, some other samples like let s = String::from("hello"); which are the result of a function call, I believe should be annotated, especially samples where the signature of the function is not readily available on the page. 24.50.56.74 (talk) 14:31, 20 August 2025 (UTC)
I'll wait another week for a response from User:Dbeef so I can hear any more detailed objections, otherwise I'll just proceed with keeping the type annotations. 24.50.56.74 (talk) 17:57, 26 August 2025 (UTC)
I'm not sure if convey[ing] as much information to the reader as possible is a realistic goal for the Wikipedia, since we already have WP:IINFO - but on the other hand that doesn't mean every bit of info shouldn't get added. (that is a roundabout way of justifying my position that "X adds information to the article" is not a good reason in and of itself to include it)
The other things you mention, such as integer falling back to i32 should be explicitly explained rather than annotating with its type (explicit annotation actually does nothing to illustrate the inference fallback).
So, again let's look at and discuss specific places where you think type annotations would be helpful instead of a unilateral edit that adds the type annotation to everything - the latter will likely get more opposes, the former is more constructive here.
I can't know for sure whether I will oppose the addition of type annotations to each case individually, you'll need to bring them up. I'm not sure whether the String::from example needs type annotations - since the signature of the function we later call makes it clear.
I don't find the often language servers will give the type annotation for that symbol anyway very convincing. People who read books on Rust won't have a language server turned on for code snippets, and those don't include type annotations. People who read around GitHub sources for fun don't have those turned on. People who just don't like it (maybe because it has clutter?) don't have it turned on. We're supposed to accurately convey to the readers what this language is in a broad sense. Overuse of explicit type annotations isn't helpful to convey that most people don't specify types.
It is also very very hard to know just what kind of readers we're targetting when they aren't satisfied by the section on types saying Rust is strongly typed and statically typed, meaning that the types of all variables must be known at compilation time. Assigning a value of a particular type to a differently typed variable causes a compilation error. Type inference is used to determine the type of variables if unspecified. It's actually a good thing to not include explicit type annotations because beginners likely don't care much about them. People who do care about types, well we have an entire section for them. We can't make every part of the article be about types. dbeef [talk] 13:04, 27 August 2025 (UTC)
Fair enough. I think, as User:Caleb Stanford suggested, we should perhaps include it on the first few examples of Rust code to indicate that indicating types of variables would appear there, and then explain that they will be inferred and perhaps give some other indication that they aren't really necessary in most cases. For example, "The example below assigns a value to the variable with name foo of type i32 and outputs its value." is an appropriate place to add the type annotation before explaining that integer types will just default to i32. I think this would also be good in demonstrating what the type looks like for mutable references, pointers, and standard library objects. Furthermore, calls to things like String::from I think are pretty reasonable to want a type annotation for, as Rust doesn't really have "constructors" in a sense, so any static method returning an instance of the struct itself should at least have the indication that it assigns String. I also think r in the second code block on lifetimes could be annotated so that it can be obvious what it is meant to be. Aside from that I would agree that there is no need to label everything with a type annotation, if it's particularly obvious and could be understood from reading something earlier in the page. But what is not obvious, should be made clear to the reader as much as possible. 24.50.56.74 (talk) 18:20, 27 August 2025 (UTC)
"The example below assigns a value to the variable with name foo of type i32 and outputs its value." is an appropriate place to add the type annotation
Agreed!
Furthermore, calls to things like String::from I think are pretty reasonable to want a type annotation for
I am with dbeef on this one - I don't see the type as being useful here, since String::from already indicates the type name. I suppose it can be mentioned in the text above that String::from constructs a new String. Though, just to note that we're an encyclopedia and not Rust documentation, so I'm not sure about explaining such things in detail in general, the goal should be to cover the main concepts of the language, not document what a function like String::from does.
side from that I would agree that there is no need to label everything with a type annotation, if it's particularly obvious and could be understood from reading something earlier in the page.
Sounds good to me - I'd say to proceed you can propose any cases you'd like to have an annotation here and we can add on a case-by-case basis. Thanks, Caleb Stanford (talk) 22:08, 27 August 2025 (UTC)

I'm missing the following information:
1. Critics. All larger articles have this section. While this article suggests that Rust is the best (or sometimes nearly the best, to C/C++) programming language, some may think it differently.
2. Compiler toolchain performance. Time is money, so it does matter. For someone using MSVC with C/C++, most problems are underlined in the editor right away. Then you get compiler warnings/errors in a few seconds, linker warnings/errors within a minute. With Rust, the parsing → AST → HIR → MIR → LLVM IR → binary compilation takes much more time, especially due to ownership checks. And it's basically like forcing a strict linter with every build.
11:18, 23 September 2025 (UTC) Yogurt (talk) 11:18, 23 September 2025 (UTC)

@Yogurt: I cannot find what you mean by the article suggesting Rust being the best language. We're just describing what Rust is and its features.
If you have reliable sources on criticism, and the compiler performance, then we can add it to the article. dbeef [talk] 16:32, 23 September 2025 (UTC)
Totally agreed on compiler toolchain performance - we should cover this & would be great to have some sources on it if you have any!
"While this article suggests that Rust is the best" I don't see where the article implies anything of the sort - can you please point to any specific language that you think states this? If there is, it's PROMO and should be updated to NPOV. Caleb Stanford (talk) 20:01, 23 September 2025 (UTC)

Hi @Jr31415: Do you have a source for the claim that it was "Network Implementation Language" and not NIL (programming language) in this edit? Your edit contains a broken (red) link. Thanks, Caleb Stanford (talk) 16:15, 30 September 2025 (UTC)

N.B.:
Possibly referring to this language:
"NIL: a high-level language for distributed systems programming"
Developed by Francis N Parr, Robert E Strom, and Shaula Yemini at IBM research. ACM DL IBM Research (1983) SIGPLAN notices (1985).
Caleb Stanford (talk) 16:20, 30 September 2025 (UTC)
I would probably go with this one:  https://dl.acm.org/doi/abs/10.1145/800226.806853
"NIL: An integrated language and system for distributed programming"
Authors: Robert E. Strom, Shaula Yemini
SIGPLAN '83: Proceedings of the 1983 ACM SIGPLAN symposium on Programming language issues in software systems
Pages 73 - 82
Published: 01 June 1983
I believe this is the main NIL article that is cited by subsequent work on typestate, though it does in turn cite the IBM Systems Journal article above. Jr31415 (talk) 00:26, 1 October 2025 (UTC)
Oh, since this is my first ever Wikipedia edit, I'll note that the broken (red) link is a reference I copied from the page on typestate analysis here: https://en.wikipedia.org/wiki/Typestate_analysis (the typestate page is reference from the Rust page).
I don't know what it takes to fix both pages, or whether it's worth it.  I doubt NIL deserves its own Wikipedia entry. Jr31415 (talk) 01:37, 1 October 2025 (UTC)
If you are linking to another Wikipedia article, put the name of the article in double brackets, like this [[Typestate analysis]]. Also, note, another Wikipedia article does not make for a good reference.War (talk) 01:58, 1 October 2025 (UTC)
Thanks! So we need a source for the fact that Rust itself was influenced by this particular NIL and not the other one. Based on current source one possible solution is to just specify in a footnote that it could be either NIL, but most likely the IBM NIL on typestates. We can't OR by deciding which one if it's not in the source, even though in this case it would appear to be fairly obvious that it's the one related to typestates... Thanks! Caleb Stanford (talk) 04:08, 1 October 2025 (UTC)
I've pushed a tempfix for now based on the above - pending a better source which links the influence directly to IBM's NIL. Caleb Stanford (talk) 04:27, 1 October 2025 (UTC)

Is there a reason why we aren't using the same footnote? dbeef [talk] 02:04, 4 October 2025 (UTC)
E.g. I fixed it in Special:Diff/1314946707 dbeef [talk] 02:06, 4 October 2025 (UTC)