Talk:Rust (programming language)/Archive 1

This is an archive of past discussions about Rust (programming language). Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

Archive 2

Archive 3

→

Archive 5

Secod code example: else necessary?

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 178.4.179.35 (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?

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 178.4.189.157 (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++

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++

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.
- In practice boundary checks can often be removed entirely and for the cases where it can't passing the size often doesn't cost anything (static size of objects -> can inline checks, cache block aligned allocation -> often free space available). Don't know if Rust actually does these kinds of optimizations and if so how efficient they are. 90.225.65.54 (talk) 19:47, 17 November 2015 (UTC)
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.
- Again many of these kinds of checks can be optimized by trivial value-tracking by the compiler. Division by zero checks could (for most computer architectures) be done via trap handling if it was worth it (it isn't in most cases due to trap handling overheads) but otherwise an explicit check against zero wouldn't make code execution less efficient - a division operation is so slow that even deep OoO processors is likely to stall waiting for the result. 90.225.65.54 (talk) 19:47, 17 November 2015 (UTC)
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)
- Cycle detection is a form of GC. 90.225.65.54 (talk) 19:47, 17 November 2015 (UTC)
- Runtime cycle detection is part of the implementation of some types of GC. Mister Mormon (talk) 22:34, 4 February 2016 (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.
- This isn't a characteristic of the language. 90.225.65.54 (talk) 19:47, 17 November 2015 (UTC)

Characteristics that might make Rust more efficient than C++

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 http://www.rust-lang.org/ front page doesn't mention systems programming.]

Pjrm (talk) 11:20, 7 May 2013 (UTC)

References

[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

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

This article relies excessively on references to primary sources. (January 2012)

We've added links to reliable secondary sources as they've become available. I see LWN.net 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 decker ^talk 18:37, 31 March 2014 (UTC)

I was going to remove that notice, because I see 41 references, with some like wired.com, infoworld, etc, but then I see that rust-lang.org is used at least 7 times, github 10 times, and a few blogs (generally frowned upon for NPOV purposes). So I'm just going to leave it as is. I see there's another section in the talk page about this also. Nerfer (talk) 20:01, 12 April 2016 (UTC)

"Appeared in" infobox date

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 (https://blog.mozilla.org/blog/2013/04/03/mozilla-and-samsung-collaborate-on-next-generation-web-browser-engine/).

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)

References

Influenced by Scheme?

"Relies too much on primary sources"

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)

@Intgr: I have seen it. Its application here is stupid. The logic behind not using primary sources is that eyewitnesses may be partial. When we're talking about the features of programming languages, or the declared intentions of its designers, partiality is not an issue, and primary sources are strictly better than secondary sources. Philgoetz (talk) 02:12, 22 October 2015 (UTC)

@Philgoetz: Primary sources are acceptable occasionally, but it's bad that the majority of descriptive statements are based on primary sources. Secondary sources are always preferable. If you think programming languages are exempt from non-neutral claims in primary sources, note that the Rust website starts out with "runs blazingly fast", clearly not something we can state on Wikipedia.

The main problem with overuse of primary sources is balance: primary are almost always pro some topic, whereas secondary sources are capable of confirming or refuting claims from primary sources. That goes against WP:NPOV

It's OK to remove some claims supported by primary sources, but don't start removing the sources alone — a primary source is still better than no source. Try to locate secondary sources that support claims already in the article, then replace the primary sources with that.

You're free to believe that these requirements are "stupid" and disagree with them, but you're expected to abide by Wikipedia's policies when contributing. Or you could participate in the community process to get the policies changed. -- intgr [talk] 07:56, 22 October 2015 (UTC)

@Intgr: I'm not saying the policies are stupid. I'm saying the mindless application of them is stupid. No policy is so precise that it can be applied robotically. Secondary sources should not be preferred over primary sources for information that can only originate from primary sources, and a rule that is designed to avoid biased information should be applied only to information that can be biased. Now consider the opening of this article: "Rust is a general-purpose, multi-paradigm, compiled programming language developed by Mozilla Research. It is designed to be a "safe, concurrent, practical language", supporting pure-functional, concurrent-actor, imperative-procedural, and object-oriented styles. The language grew out of a personal project by Mozilla employee Graydon Hoare. Mozilla began sponsoring the project in 2009 and announced it in 2010. The same year, work shifted from the initial compiler (written in OCaml) to the self-hosting compiler written in Rust. Known as rustc, it successfully compiled itself in 2011. rustc uses LLVM as its back end. The first numbered pre-alpha release of the Rust compiler occurred in January 2012. Rust 1.0, the first stable release, was released on May 15, 2015."

Every claim in that passage, with the exception of "multi-paradigm", which is simply vague, is either a claim that's objectively true or false, or a claim about the intent of Rust's designers. The former are not vulnerable to bias. They could be incorrect, but saying that Mozilla might be lying about when it developed Rust, or who developed it, or what language it was written in, or how it operates internally, and so this all needs to be verified by a secondary source, would be setting Wikipedia up as an investigative agency ala snopes.com rather than as an encyclopedia. And if you try to find a secondary source to say that rustc uses LLVM as its back end, you're not going to find a secondary source that has hacked into Mozilla's servers and disassembled the rustc object code. You're going to find somebody who recited the primary source without citing it.

The latter, claims about intent, are only available by reports from the designers. It's possible they're mistaken about their intents, but citing a secondary source citing them wouldn't reduce bias.

So the charge against this article that it needs fewer primary sources threatens to eliminate information that isn't available from secondary sources, except when they are merely reciting the primary source. Promulgating the idea that in such cases you can safeguard against bias by playing telephone with the primary source could only degrade accuracy and completeness. Philgoetz (talk) 17:35, 7 December 2015 (UTC)

Talk:Rust (programming language)/Archive 1

Secod code example: else necessary?

Why are they not using Rust for Firefox?

Performance of Rust compared to C++

Characteristics that might make Rust less efficient than C++

Characteristics that might make Rust more efficient than C++

References

De-primary source-ification

"Appeared in" infobox date

Influenced by Scheme?

"Relies too much on primary sources"

The Goal of Rust

Linear vs. affine typing

Source of Rust's name

List of "Project using Rust"

Actor Concurrency Model

Related Articles