Talk:Rust (programming language)

Adding the type annotations to code snippets

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)

Missing

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)

If there's no Critics section, no drawbacks mentioned at all, it might look as if Rust were perfect. (Compare the article with other programming languages.) It's also underlined with the first Rust CVE in the Linux kernel recently.

Regarding practical issues, I would have added it in the article if I wanted to. Instead, I put a note here for someone to write an unbiased criticism, probably backed with a few relevant measurements. 06:39, 20 December 2025 (UTC) Yogurt (talk) 06:39, 20 December 2025 (UTC)

@Yogurt: The idea of comparing the Rust article to other articles runs into problems of WP:OTHERCONTENT. A quick glance at the Java's criticism section tells me that it is mostly using primary sources such as blogposts, and don't appear very reliable. For the first CVE in Linux, we could try incorporating https://itsfoss.com/news/first-linux-kernel-rust-cve/, though that's not a very reliable source either. (We can't use phoronix here, see recent discussion on that) There's also https://thenewstack.io/where-does-the-time-go-rusts-problem-with-slow-compiles/ for compile times, although I think still marginally reliable.

I'm not telling you that we shouldn't incorporate the suggestions you have laid out here, but that Wikipedia is an encyclopedia that anyone can edit, so if you have reliable sources that cover this, you are free to add it or list them here so someone else (probably me) can add it. I am quite sure that the lack of a criticism section on this article has just mainly been not having someone sitting down and gathering sources to write it. dbeef [talk] 16:03, 20 December 2025 (UTC)

If there's no Critics section, no drawbacks mentioned at all, it might look as if Rust were perfect

I have trouble understanding how a reasonable person could come away with this conclusion. Does anyone believe that any language is perfect?

Compare the article with other programming languages.

C++ and Python do not have "criticism" sections. There is a separate article, Criticism of C++.

the first Rust CVE in the Linux kernel recently.

IMO, probably notable to mention. I can check for press sources if I get the chance. Caleb Stanford (talk) 19:30, 20 December 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)

Network Implementation Language

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)

Compiler unsoundness

@Caleb Stanford: I don't think there is a coverage of that compiler bug in any reliable sources, and as such we shouldn't be giving it WP:UNDUE weight, given that the only sources being used are a GitHub repo and a GitHub issue. While the example is interesting and deserves discussion in PL/compiler design (see https://counterexamples.org/nearly-universal.html), I don't think it's something we should cover. dbeef [talk] 15:20, 8 December 2025 (UTC)

Hi @Dbeef: thanks for initiating, I was thinking about reaching out on the talk page about this.

Full disclosure, I have a peer-reviewed research paper on this topic (see here). Obviously, I would not want to link my own paper :-)

It's far from a single example, and is a known issue that there are soundness bugs in the compiler. In addition to the other link you provided, see issues tagged l-unsound (108 results). This is probably not unique to Rust but is a broader problem. However, how would you measure whether it is WP:UNDUE weight in this case?

I don't wish to give undue weight, at the same time, I don't wish to "comb over" or hide the fact that there are open issues in rustc. In a section specifically about safety and soundness, it seemed appropriate to mention, well, actual known *unsoundness* that is present.

Thanks! Caleb Stanford (talk) 18:45, 8 December 2025 (UTC)

@Caleb Stanford: Our facts must be verifiable, so they need reliable sources. WP:SELFCITE is fine, although I might try to cite your paper once I get to it. The ones that are currently there are all primary and self-published or user-generated. dbeef [talk] 16:11, 20 December 2025 (UTC)

Agreed and thanks! Caleb Stanford (talk) 19:21, 20 December 2025 (UTC)

[1] might be useful (as well as maybe the introduction for [2])? Sohom (talk) 16:14, 20 December 2025 (UTC)

yes! also this and this are canonical references if we don't already cite them. Caleb Stanford (talk) 19:22, 20 December 2025 (UTC)

It's very clear to me, that this mention is giving it undue weight, unless it can be shown that the soundness bugs cause frequent problems and are a serious issue. We can draw an analogy to type systems and memory management systems in other languages. The compiler is a program and like all programs, it will have bugs. This will be true for Rust as well as for every other programming language in existence. Rust is unique in that it is the only mainstream language with a borrow checker, but most languages have type systems and many garbage collected languages promise to be memory safe. Those, too, will have obscure bugs in their type systems or memory management systems that cause unsafety that they were supposed to protect you from. You won't find mentions of that on their wiki pages. The rustc team has labeled these issues very neatly, but for example Python and Go also have their issue trackers on Github and a quick search shows many results when searching for segfaults or memory corruptions.

To be extra clear, I am not referring to flaws like the lack of data race safety in Go or the existence of type unsoundness in Java. These are issues that exist by design. I am talking about soundness and safety problems that exist from bugs. You will find those everywhere. As far as the design of the safety systems in Rust go, there exists at least a proof of the correctness of the model for a significant subset of it (https://people.mpi-sws.org/~dreyer/papers/rustbelt/paper.pdf)

Caleb's paper is frankly a bit strange. Beyond the compiler soundness holes, it mentions things that are out of scope of Rust and it builds a link between security concerns and memory safety that is on its head. Usually, you care for memory safety because of its effects on security (among other things). You could exploit memory unsafety to achieve remote code execution for example. The paper then argues that you can also use remote code execution to violate memory safety. That is a strangely specific notion, given that you could use it for almost anything and inject malware whereever you want. For the file access unsafety, the paper even explicitly acknowledges that this is out of scope of Rust.

Sorry for the rant by some random drive-by editor. It's a nice article.

In the spirit of being bold, I'm gonna go ahead and remove the paragraph. Feel free to revert, if you wish. I'm not usually editing and will most likely not check in again. ~2025-43690-42 (talk) 02:46, 29 December 2025 (UTC)

Hi @~2025-43690-42: Thanks for engaging with the article! I made a few edits.

Re: safety paragraph, agree about removing it for now, as it seems to be considered WP:UNDUE as currently mentioned (i.e, all compilers have bugs). However, I don't think it's UNDUE to mention soundness in some way, as this is an issue that is mentioned in multiple reliable sources. BTW, I think RustBelt should be mentioned also.

Re: the paper - yes, that's a reasonable criticism. The focus was features of Rust that can be used to violate memory safety. The fact this can be done via executing arbitrary code or other more general security holes *is* the point.

(May I suggest that you register an account? It helps demonstrate good faith and is helpful when engaging with other users.)

Caleb Stanford (talk) 23:27, 31 December 2025 (UTC)

I am not sure what you mean by soundness. Third party libraries are out of the picture imo. The standard library is quite fast at fixing unsound APIs. The only remaining "unsoundness" is in the compiler. And those are compiler bugs. I mostly ask myself "What are the relevant facts when explaining to a broad audience regarding Rust's safety?" And I don't find compiler bugs relevant. It could matter a lot to Hacker News (the site where I see the specific bug mentioned the most) people who might see it as a huge flaw of the language. But really compiler bugs either always require nightly or exploit the compiler in a way that it would be impossible to accidentally bump into. It's not something anyone aiming to get a general understanding of Rust should care about. dbeef [talk] 23:14, 1 January 2026 (UTC)

I am not sure what you mean by soundness

I meant compiler unsoundness and to a lesser extent, unsoundness in the standard library. Sorry for the sloppy wording.

I mostly ask myself "What are the relevant facts when explaining to a broad audience regarding Rust's safety?" And I don't find compiler bugs relevant.

So I'm not necessarily saying this is incorrect, but I think we should lean on what RS have to say on the matter. (I.e., if there is coverage in RS, then probably notable to mention.) Whether and to what extent Rust's safety guarantees actually translate to arbitrary (safe) Rust code is a question that has been of interest to several research papers by different groups (linked above), there may be others.

The standard library is quite fast at fixing unsound APIs. ... But really compiler bugs either always require nightly or exploit the compiler in a way that it would be impossible to accidentally bump into.

 :) Caleb Stanford (talk) 00:47, 2 January 2026 (UTC)

Speykious/cve-rs is not a reliable source. counterexamples is reliable (imo, published by subject matter expert) but it doesn't discuss the significance of the bug to Rust. The GitHub issue rust-lang/rust/issues/25860 could be used to verify that the bug indeed exists, but this is not adequate sourcing.

I am interested in knowing what exactly you wish to include, but, yes, per WP:SOURCE, I am interested in what independent reliable sources have to say about Rust's safety.

Hui Xu et al.: All memory-safety bugs of Rust except compiler bugs require unsafe code. The main magic lies in that Rust enforces the soundness requirement on APIs provided by both Rust standard library or third-party libraries. As a result, many bugs in our dataset are mild soundness issues and these bugs have not incurred severe memory-safety problems. Besides, the trend of compiler bugs is much stable. Therefore, we can conclude the effectiveness of Rust in preventing memory-safety bugs. As for its RQ 1.3 which looks into issues labeled I-unsound, I see no claims about how that relates to actual safety problems. Clicking on those issues https://github.com/rust-lang/rust/issues?q=is%3Aissue%20state%3Aopen%20label%3AI-unsound would reveal that many of these require nightly features.

I'd also be curious on what facts you can draw from Zixi Liu et al. to write for this article. They say most bugs are found in MIR and HIR and say that is caused by Rust's type system and lifetime model. But IMO that's really because rustc does the most work on MIR and HIR and the study has explicitly excluded LLVM related bugs. dbeef [talk] 18:04, 2 January 2026 (UTC)

Rust standard library page

Could we ever get a page for the Rust standard library? I think it's distinct enough to warrant its own topic, has an abundance of material that could be covered, and there are already precedents for such a page (see C++ standard library, Java Class Library, Standard Libraries (CLI), etc.) ~2026-49007-4 (talk) 16:51, 27 January 2026 (UTC)

@Dbeef @Caleb Stanford You two seem to be very involved in the page's development. Do you have any thoughts?

~2026-49007-4 (talk) 17:49, 29 January 2026 (UTC)

please consider creating an account! It has many benefits, and is helpful to demonstrate good faith when communicating with others.

I currently don't have time to spearhead this, but it seems like a reasonable idea to me. Caleb Stanford (talk) 20:39, 29 January 2026 (UTC)