Talk:Rust (programming language)

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)

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)

might be useful (as well as maybe the introduction for )? 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)

Fully qualifying types outside of the prelude

@Caleb Stanford Types that reside outside of the prelude should be fully qualified, and my reasoning is that because they reside outside of the prelude they are not readily available without a use statement and their namespace is not obvious. (Obviously, items inside the prelude don't need to be fully qualified except in contexts where it matters, such as distinguishing between std::result::Result and std::io::Result.) ~2026-54311-03 (talk) 18:34, 10 October 2026 (UTC)

it's not needed. The namespaces are really a distraction that hinders readability. The best I can explain this is the goal of Wikipedia is not to be a user manual or have every piece of inline code compile exactly as is. It's to be a general compendium of knowledge on the topic, if people want to know what's in the Rust prelude they can go to the Rust documentation or play around with the language itself. @Dbeef: or others welcome to weigh in. Caleb Stanford (talk) 21:46, 10 October 2026 (UTC)

Yeah, I think it's information that the average reader wouldn't be very interested in. dbeef [talk] 21:52, 10 October 2026 (UTC)

It is nomenclature that is valuable. There are sentences like 4..=10 is a value of type Range that implements the Iterator trait., which give the impression that Range is a globally available type the same way Vec and Option are, when it is not. Additionally, while some symbols that do exist outside the prelude are commonly used (like std::collections::HashMap), others are much less common, such as std::ops::Drop; and especially for less common types like these, the clearer nomenclature adds specificity.

Additionally, I do not agree that the namespaces are distracting or obstructing to readability, but I think it would also be reasonable only to show the full namespace of symbols outside the prelude on their first appearance, and after it is introduced the unqualified name can be showed subsequently.

Most of what exists on this page is better suited for Rust syntax, and as you said yourself that this is not a user manual; I do hope this is something that I can bring your attention to. There is nothing wrong with a programming language's main page having a long section on syntax or language features, but I do think that the more specific details about the language are better suited in the Rust syntax page a la WP:AUDIENCE.

~2026-54311-03 (talk) 22:32, 10 October 2026 (UTC)

> which give the impression that

It gives no such impression, unless you are being overly pedantic. Humans are not compilers. Caleb Stanford (talk) 01:15, 11 October 2026 (UTC)

It certainly gives ME that impression, for that matter. I showed a substantial amount of WP:GOODFAITH in my previous response, and I would appreciate not reducing my replies to a single sentence and leaving the rest unaddressed. ~2026-54311-03 (talk) 02:59, 11 October 2026 (UTC)

My apologies, I didn't mean to offend, but to make a point about how syntax should be (and I believe, typically is) read by most readers. I don't think it will be productive to discuss this further, but feel free to solicit opinions from other users. Caleb Stanford (talk) 03:08, 11 October 2026 (UTC)

Thanks, I likewise am sorry for misinterpreting your response. I won't press this specific issue further until any others with an opinion to share have done so, but I do think moving more intricate details into the Rust syntax page is a worthwhile exercise; the page covers many details that are typically beyond the horizon of a non-programming audience's interest, such as discussing std::ops::Drop or the inner workings of std::ffi. ~2026-54311-03 (talk) 03:22, 11 October 2026 (UTC)

It would be nice to go through the syntax / semantics discussed by the main article and identify which ones would be more suitable for the Rust syntax article instead.

I think a nice way could be to add a footnote to each non-prelude type we showcase, and in the footnote state the full path needed. Its specific location in the standard library is less relevant when we're trying to give an overview of what Rust provides. dbeef [talk] 05:05, 11 October 2026 (UTC)

OK, I agree that going through the page would be a reasonable way of cleaning up the article of the more intricate, non-layman details.

Also, I think the footnote approach is a good idea, especially on a page like this which is oriented for casual readers rather than computer science-literate readers, who may not appreciate/understand the details of the symbol's full name. ~2026-54311-03 (talk) 07:35, 11 October 2026 (UTC)