Talk:Rust (programming language)

From Wikipedia, the free encyclopedia
Jump to: navigation, search
          This article is of interest to the following WikiProjects:
WikiProject Computer science  
WikiProject icon This article is within the scope of WikiProject Computer science, a collaborative effort to improve the coverage of Computer science related articles on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 ???  This article has not yet received a rating on the project's quality scale.
 ???  This article has not yet received a rating on the project's importance scale.
WikiProject Computing / Software  
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 ???  This article has not yet received a rating on the project's quality scale.
 ???  This article has not yet received a rating on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Software.
WikiProject Mozilla (Rated C-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Mozilla, a collaborative effort to improve the coverage of Mozilla and its products on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
C-Class article C  This article has been rated as C-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.

Secod code example: else necessary?[edit]

Hi. Im not that good with rust or other prog. languages but in the second code example:

fn fac_recur(n: int) -> int {
    if n <= 1 { 1 }
    else { n * fac_recur(n-1) }

Is there the "else" really necessary? I mean if the first "if" statemant is not true you will automaticly return n * fac_recur(n-1) with and without else right? — Preceding unsigned comment added by (talk) 13:04, 21 December 2012 (UTC)

If I understand correctly, you're suggesting removing the else block but keeping the n * fac_recur(n-1) within it. That would actually change the behaviour of the program, because the 1 expression above it would never be returned. (That could be mitigated by changing { 1 } into { return 1 }, however it's better Rust style to use implicit returns.) Hope that makes sense! Thanks. Hexene (talk) 12:31, 29 December 2012 (UTC)
I concur with Hexene. Much of the interest in that code example is to demonstrate that `if` is an expression with a return value, which is a foreign concept to anyone familiar with only C/C++/Java. To demonstrate this, the `if` needs to be the last expression in the function. As Hexene notes, this is also a very common style in Rust, and is a good demonstration of idiomatic code. Kibwen (talk) 16:35, 4 January 2014 (UTC)

Why are they not using Rust for Firefox?[edit]

So this is a good new language. But why is not even Mozilla using this?! Like for firefox? Its somehow funny, that they create an own language - but they are not using it. — Preceding unsigned comment added by (talk) 09:00, 26 January 2013 (UTC)

See Servo (layout engine). Rust is still an experimental programming language under heavy development. It is being designed by Mozilla specifically to rewrite their entire layout engine in it. Programming languages and layout engines, however, are complicated things that take years to develop from scratch like this.
I think it will take at least another two years for a Rust-based rendering engine to be, or start to be, viable for real world usage. Servo has yet to pass the Acid1 test, and is using all manner of temporary components (such as libhubbub, the NetSurf HTML parser) whilst Rust replacements are being designed and written. As an outsider looking in, I have great faith in the project, but it will take time. Hexene (talk) 20:13, 8 April 2013 (UTC)
FYI, Servo now passes Acid1 test. Sanxiyn (talk) 08:03, 3 October 2013 (UTC)
Two years was a good guess :) Servo is getting close to usable and Mozilla is starting to integrate some of its components in Firefox. DdEe4Aai (talk) 18:19, 7 May 2015 (UTC)

Performance of Rust compared to C++[edit]

Rust has often been presented to people as a high-performance language, comparable to C++ and suitable in many places where C++ might otherwise be used. This makes it particularly valuable to compare efficiency of Rust with C++, not just with benchmarks that measure today's immature compiler but looking at aspects of the language that might make it faster or slower than C++ once the language has been around for a couple of decades.

Here's a start towards some content that provides such a comparison (sometimes still using first person due to its tentative nature). I include it here partly as it may be of some value to others even in its current state, and partly so that others might help fill in some of the gaps and help bring it towards something that can be moved to the main article. Pjrm (talk) 14:00, 2 May 2013 (UTC)

Characteristics that might make Rust less efficient than C++[edit]

  • Nullable pointers seem to need an explicit tag, i.e. take up more space than in C++. This reduces cache hotness.
    • This was a bug, and now fixed in the latest version. Sanxiyn (talk) 15:36, 16 September 2013 (UTC)
  • Unions are always tagged (and tags are always part of the object rather than separating the tag when two or more objects are required to have the same tag).
    • Rust specification doesn't actually require the tag to be a part of the object so in principle, this is optimizable. However I think that the current implementation doesn't do any optimizations with this. GolDDranks (talk) 13:18, 20 May 2015 (UTC)
  • Bounds checks are mandatory, so need both the check itself and for size data to be passed around.
  • Certain arithmetic checks (e.g. division by zero; not sure how int wraparound or shift bounds are handled) also involve software runtime checks in Rust.
  • Memory management is more restricted, so there are probably more use of heap rather than stack for arrays, more reference-counting operations, more use of GC, and more copying than in C++.
    • However, runtime-cautious C++ code might be slower than Rust, because Rust provides compiler-checked pointer owning semantics, and (as Rust compilers mature) it might be more likely for the compiler to optimize away some reference-counting operations because of these being part of the language.
  • I believe there's also more house-keeping of memory allocations to provide for cycle-detection, perhaps even when GC isn't being used.
    • This is not true. Rust doesn't detect cycles and explicitly warrants that memory can be leaked in some cases because cycles aren't detected automatically. GolDDranks (talk) 13:18, 20 May 2015 (UTC)
  • Rust seems to require data (variables, fields, arrays) to be initialized in situations where the compiler doesn't know that this isn't necessary, e.g. because the compiler doesn't know that a foreign function won't consult the existing values. There don't seem to be many (or any) ways of letting the compiler know when initialialization isn't necessary.
    • This was a bug, and now fixed in the latest version. You still need to initialize everything in the safe language, but you can tell the compiler "believe me, it doesn't need initialization". Sanxiyn (talk) 15:48, 16 September 2013 (UTC)
  • Rust has fragmented stacks (to allow for concurrency and multiple stacks in an address space), which might well incur a cost in stack adjustment: i.e. this very likely needs runtime checks to see how much to increase or decrease the stack pointer.
    • If this means segmented stacks, this is not true anymore. Rust opted out from green threads and uses currently OS threads. GolDDranks (talk) 13:18, 20 May 2015 (UTC)
  • Strings might be another area that often results in more copying in Rust than in C++, e.g. due to what looks like a distinction between strings and byte arrays. E.g. the SHA1 example in /doc/tutorial-ffi.html looks like it's doing one copy from string to foreign byte array, then another copy from foreign byte array to vec.
  • Rust's initial implementation (I think true as at v0.6) generates bigger binaries than for the "equivalent" C++ programs. I don't know how much of this is fixable, and how much this affects performance (cache hotness).
    • This is partly because C++ defaults to dynamic linking, while Rust defaults to static linking. There's a lot to shave off though. I think many dead code optimizations are not yet implemented. GolDDranks (talk) 13:18, 20 May 2015 (UTC)
  • External reasons: for at least the next decade, there is likely to be more C++ code than Rust code in use in the world, and more performance-critical code in particular is written in C++ than in Rust, such that more effort is likely to have been expended to improve C++ performance than Rust performance.

Characteristics that might make Rust more efficient than C++[edit]

  • More convenient parallelism.
  • Availability of compiler-checked owned pointers: a programmer might in some circumstances use owned pointers if writing in Rust, while using slower runtime checking if writing in C++.
  • In Rust enum types, the compiler has the option of implementing method dispatch as a switch on the tag value (because the full set of "subclasses" is known to the compiler), which might be faster than using a vtable on some CPUs, due to better branch prediction and locality (not needing to consult a distant vtable).
  • Knowing the full set of possible subclasses also makes inlining feasible.
  • Knowing the full set of possibilities also theoretically improves compiler knowledge of the behaviour of the call.
    • C++ programmers have the option of doing this (manually using a tagged representation and switching on that tag value), but it requires more work (not just for method dispatch but also manually invoking the "virtual destructor"), and has more likelihood of mistakes, so is much less common.
    • (The corresponding functional disadvantage is that unrelated code can't create a new subclass of enum types, unlike with vtable-based types.)
  • Rust tries harder than C++ to have data considered as immutable, which might lead to the compiler more often knowing that a field can't have changed value, leading to fewer memory accesses. However, I haven't looked into whether this possible advantage does eventuate: even if the language theoretically facilitates this optimization (and I haven't yet checked that it does), it still requires that this information is passed to the middle-end (LLVM).
  • Rust's memory approach might make arenas more convenient, i.e. the compiler might be able to coalesce multiple frees into a single free more commonly in rust than in C++ unless the programmer goes to unusual effort to implement the arena for the C++ case. (Nevertheless, my impression is that Rust code tends to involve more underlying free() operations than in C++ due partly to arena marking being relatively rare, and mostly due to the above-mentioned greater use of copies & heap in Rust compared to typical C++ code.)
  • Rust has various annotations to help efficiency (noalias, nocapture, nounwind, readonly, readnone, optsize). todo: Look at their documentation: some of these might give performance advantages over C++; others might have C++ equivalents; others might not be necessary in C++; others might give theoretical advantages but not in practice fed to middle end.
Wow, lots of interesting detail there! I think we should work towards a new section, either 'Comparison of Rust and C++' or perhaps something like 'Design contraints in terms of performance'. The latter would certainly have a lot to say about C++, but also other issues such as tail call optimisation.[1] I terms of the 'Description' part of the article as it currently stands, I feel we need to be brief, which is why I prefer the “Performance should be comparable to idiomatic C++” over “Performance is expected to be slower than C++ if performance is the only consideration, but to be comparable (and sometimes faster) than C++ code that manually takes precautions comparable to what the Rust language mandates.” Thanks, Dave. Hexene (talk) 10:35, 6 May 2013 (UTC)
The problem with the previous “comparable to idiomatic C++” formulation is that it seems to assume that “idiomatic” means “lots of runtime precautions against self-bugs”. That might be idiomatic in Gecko code, and in some respects in a lot of GUI software, but in my experience is atypical of systems software (such as the Linux kernel) — which is significant because both C++ and Rust are described[2] as intended for systems programming.
I considered “Performance is expected to be slower than idiomatic C++ in systems programming contexts, but comparable in applications programming contexts.” as a briefer way of capturing this, though I wonder whether this shorter approach is too cryptic. OTOH, the interested reader could read the footnote.
[If we were to accept that Rust is intended as a systems programming language, then we could even shorten that by dropping the "comparable for applications programming" half and saying just "slower for the two languages' intended role of systems programming"; but it's hard to accept that Rust is intended more for systems programming such as Linux than for Gecko-like programming! The front page doesn't mention systems programming.]
Pjrm (talk) 11:20, 7 May 2013 (UTC)


  1. ^ Hoare, Graydon (2013-04-10). "[rust-dev] Tail call optimization". Retrieved 2013-05-06. … Their absence is heartache and sadness, not arrived-at lightly… Tail calls “play badly” with deterministic destruction… 
  2. ^ Anderson, Brian (2013-04-03). "[rust-dev] Rust 0.6 released". Retrieved 2013-05-07. Rust is a systems programming language with a focus on …, performance and …. 

De-primary source-ification[edit]

It would be marvelous to be able to remove this large box from the top of the article:

We've added links to reliable secondary sources as they've become available. I see has published about Rust for a second week in a row, which is great; meanwhile Dr Dobbs suggested Rust was on their radar and they'd dedicate some articles to it, but this hasn't come about yet. Unfortunately there are key (primary source) links which I really don't want to remove from here as IMHO they add a lot of value. It would be great if future secondary sources either included the links or failing that covered the same issues -- then I think we'd have the opportunity to either remove the primary sources ourselves, or at least include secondary sources alongside each primary one. (Which would be the best approach? Any opinions?) It could be argued that some links to primary sources are superfluous already, e.g. the link to the Rust COPYRIGHT file from the infobox, and could be deleted. Thanks, Dave. Hexene (talk) 11:17, 6 May 2013 (UTC)

Primary sources are fine for facts, such as a project's license. They become problematic when used for analysis or synthesis. See WP:PRIMARY. Jruderman (talk) 00:16, 14 June 2013 (UTC)
I generally prefer to add secondary sources alongside primary sources, rather than replacing primary sources outright. Jruderman (talk) 00:16, 14 June 2013 (UTC)
I suspect that part of the remaining primary sources exist largely to support non-encyclopedic content. The article ventures a little too far, in my view, into HOWTO territory, and reads a little more like an ad for the language than an encyclepdic summary. Refocusing what the article actually says to emphasize those aspects of Rust covered by secondary sources, and away from those not covered by secondary sources, would address both problems. See WP:NOTHOWTO. --j⚛e deckertalk 18:37, 31 March 2014 (UTC)

"Appeared in" infobox date[edit]

Throughout the history of this article the "Appeared in" date has been repeatedly changed to any of the following: 2006 (often cited as when Graydon started conceiving the language), 2009 (the year Mozilla started letting him tinker with it on company time), 2010 (the year it was first mentioned at an internal Mozilla conference), 2011 (the year that the compiler was bootstrapped), and 2012 (the year of the first public pre-release). It could also be argued that 2013 could also appear here, as it was the first year that Rust was mentioned (as well as demonstrated, along with Servo) at a Mozilla event that was open to outsiders (Mozilla Summit 2013). In addition, 2013 was when Mozilla publicly announced their partnership with Samsung regarding Servo, which was the impetus for Rust in the first place (

After consideration I've decided to settle on 2012, and I'll be reverting changes that are made without coming here to discuss it first.

Obviously this discussion will depend on a given interpretation of "Appeared in", which I choose to interpret as "the year in which the language was first publicized". This is complicated by the fact that Mozilla doesn't generally bother to keep any of its projects a secret, so we cannot merely conflate "the date that a small number of people outside the company heard about this" (such as with the 2010 Future Tense conference) with an act of deliberate discretion. It seems to me that the 0.1 release in 2012 is the best candidate for when Mozilla chose to begin a public discussion on Rust. I could also be convinced that 2013 would be a good date given the previously-mentioned press release regarding the Samsung/Mozilla partnership, which AFAIK is the first Mozilla press release to ever mention Rust.

For precedence, note that the article on Python cites 1991 as the "Appeared in" date, which was the date of the first published code release (see History of Python).

Kibwen (talk) 17:44, 4 January 2014 (UTC)

Rust's first public appearance was in 2010, the date of the first git commit publicly viewable on github. At that time, public discussion of Rust began. ~Mlzg4~ (talk) 09:01, 5 May 2015 (UTC)

See, for example [1], [2], [3], and [4]. ~Mlzg4~ (talk) 09:06, 5 May 2015 (UTC)


Influenced by Scheme?[edit]

Rust has hygienic macros. Were these not invented for and first standardized in Scheme? (Appendix in R4RS, part of main document in R5RS. Research prior to those documents was also closely tied with the Scheme community if I'm not mistaken (could be mistaken).)

Also, closures. They were first implemented in Scheme (were one of the hallmark features of the very first Scheme paper) if I'm not mistaken. Equivalent to Hewitt's actors model, yes, but closures as first-class functions and "lambda" and all as we know it today comes directly from Scheme. (Lambda in prior Lisps did not create closures.)

Therefore I added it as an influence. Hope that's OK. 2003:51:4A1D:E440:213:E8FF:FEED:36FB (talk) 21:10, 8 September 2014 (UTC)

"Relies too much on primary sources"[edit]

This article has a note at the beginning from some editor saying, "This article relies too much on references to primary sources. Please improve this article by adding secondary or tertiary sources. (January 2012)." This may literally be the dumbest criticism I have ever heard. Primary sources are good. Tertiary sources are bad. Philgoetz (talk) 17:39, 23 January 2015 (UTC)

@Philgoetz: No, primary sources are not good. See WP:PSTS and WP:RS. -- intgr [talk] 08:09, 23 February 2015 (UTC)
So, is it OK to remove the primary sources? Bevo (talk) 04:35, 9 July 2015 (UTC)

The Goal of Rust[edit]

The first sentence in

"The goal of Rust is to be a good language for the creation of large client and server programs that run over the Internet"

This strikes me as a very poor description of the Rust programming language and its goals. First of all programs do not "run" over the Internet. Second, Rust has been shown to be a viable programming language for Kernels( and Embedded Systems ( I'm not sure what it should say here, but the current description should not stand. — Preceding unsigned comment added by (talk) 00:26, 23 February 2015 (UTC)

Linear vs. affine typing[edit]

Under the "Typing discipline" section of the infobox I've added that Rust features a linear type system. In the past this has been occasionally controversial from people who believe that Rust has an affine type system instead. I've linked to the section on linear typing for the following two reasons: first, the linear camp argues that every value is, in fact, used exactly once, and that usage occurs when the value is reclaimed by RAII and triggers its destructor, so the dispute between linear and affine typing is largely academic (no pun intended); second, the linked section on linear type systems mention C++'s std::unique_ptr type which is analogous to (though weaker than) Rust's ownership system, and it's not self-consistent to pretend that one of these is affine while the other is linear. Any attempt to change the infobox should first edit the Substructural type system page to ensure this inconsistency does not hold. Kibwen (talk) 20:53, 26 March 2015 (UTC)

Source of Rust's name[edit]

Stating that Rust is named after the fungi seems like far too definite/limited a summary of the chat with which that statement is sourced, which mentions many other possible rationales for the name. — Preceding unsigned comment added by (talk) 20:35, 22 September 2015 (UTC)