Talk:Rust (programming language)/Archive 2

Archive 1

Archive 2

Archive 3

External links modified

Hello fellow Wikipedians,

I have just added archive links to one external link on Rust (programming language). Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

• Added archive https://web.archive.org/20141225103820/https://github.com/idris-lang/Idris-dev/wiki/Uniqueness-Types to https://github.com/idris-lang/Idris-dev/wiki/Uniqueness-Types

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 17:39, 25 February 2016 (UTC)

Definition of terms

The term "mutated" is used in a code comment. Please define terms, thanks! 24.18.30.76 (talk) 20:39, 17 July 2016 (UTC)24.18.30.76 (talk) 20:39, 17 July 2016 (UTC)

Borrow checker

Borrow checker currently redirects to Rust (programming language) but is never mentioned on that page. Should the redirect be deleted or is there some more appropriate target for that redirect?—Tea2min (talk) 18:48, 15 January 2017 (UTC)

I would say that the borrow checker (or linear or affine types) deserves a mention in the article. It is one of the relatively distinctive features of Rust. JustinBlank (talk) 16:01, 20 January 2017 (UTC)

Efficiency

Would be useful to have some kind of indication of compile and execution efficiency. All the best: Rich Farmbrough, 20:39, 16 April 2017 (UTC).

General Purpose Programming Language

The Rust folks at rust-lang.org refer to it as a "systems programming language". The reference for calling it a "general purpose programming language" also refers to it as a "systems programming language". So if the description is not changed, the reference needs to be removed since the text disagrees with it's own reference. Wickorama (talk) 21:28, 24 March 2017 (UTC)

I do not think these are exclusive terms. While not definitive, the wiki page on general purpose programming languages includes several systems programming languages, including Ada, C, and C++. JustinBlank (talk) 13:56, 18 April 2017 (UTC)

Confusing example code

Does the thread example use green threads or OS threads? And does Rust provide tail recursion optimization? If not, I am not sure it is appropriate to have the factorial implemented like that. --Ysangkok (talk) 21:33, 27 April 2016 (UTC)

Rust removed green threads before 1.0 and I'm not too sure on the tail recursion but I think it does.69.26.74.42 (talk) 19:03, 26 May 2016 (UTC)

Rust uses os threads. rust can do tail recursion optimisation, but does not guarantee it, it leaves it to llvm to do it. 178.24.156.98 (talk) 11:09, 24 April 2017 (UTC)

Use of examples

This is an encylopedia article. It describes a subject from reliable secondary sources. It does not attempt to teach content, and it is not a showcase for random editors' clever use of their software development experience. If we need example code, it should be to demonstrate specific features or syntax, and integrated into the relevant sections. It should not be an open-ended, arbitrary library of code snippets with no supporting references (because let's face it, all of this code is written by editors themselves to demonstrate how clever they are) tacked onto the end. Chris Cunningham (user:thumperward) (talk) 14:29, 20 August 2017 (UTC)

Traits and Inheritance

The history section says that "traits were added as a means to provide inheritance". I think the word "inheritance" is inaccurate, but I don't know a better word. JustinBlank (talk) 13:52, 18 April 2017 (UTC)

I would probably say "code reuse" instead of inheritance to distance it from any implicit connotations the term may provide. The term "inheritance" refers to a very specific kind of object-oriented code reuse which Rust does not provide, so perhaps simply saying "code reuse" as a more general term might suffice. Eyal Kalderon (talk) 05:21, 5 June 2018 (UTC)

Add references to published books?

Hello, I'm unsure of the right WP rule but I wonder if external links to published books, esp. O'Reilly's Programming Rust and No Starch's Rust Programming Language. I am the author of Rust in Action by Manning, but I will allow others to advocate for its inclusion :) TimClicks (talk) 19:58, 9 March 2018 (UTC)

I would not object to a short list of pertinent books. It's usually done as a "Further reading section, added between the "References" and "External links" section. A typical and vendor-neutral form for the content (Using the O'Reilly book as an example) might be:

• Blandy, Jim; Orendorff, Jason (2017). Programming Rust: Fast, Safe Systems Development. O'Reilly. ISBN 1491927283.

I would not object to including your Rust in Action book once it is published, particularly if it gets some reviews; but with "Publication in Early 2019,"it's way too premature. The point of the "Further reading" section is to provide a reader with information about what else they could read now to get more information.

Is Rust Programming Language a published book? Looking at [1], it appears to be online-only; so would be more appropriate as an external link than as a further reading entry. But with rust-lang.org already an EL, we don't usually add a second one for the documentation.

The print edition of Rust Programming Language has recently been released by as "Klabnik, Steve; Nichols, Carol (June 2018). The Rust Programming Language. No Starch Press. ISBN 978-1-59327-828-1." TimClicks (talk) 08:36, 20 July 2018 (UTC)

Incidentally, kudos to you from bringing this up on the talk page instead of plunging right in and using the article to promote your book. I really appreciate it. TJRC (talk) 23:05, 9 March 2018 (UTC)

References

Yeah, definitely high marks for asking first. I suppose one of the difficulties of including books purely because they're about the language is that such lists tend to date fairly rapidly. On the other hand, if a reliable volume could be used as a ref within the article, that might be easier to incorporate. Basie (talk) 19:38, 21 May 2018 (UTC)

Thanks - although I'm keen for an extra sale or so, my main motivations for asking the question were to reinforce that Rust is a mature programming language (publishers have decided books about it) and to guide learners to resources. Hopefully my text will make the cut of quality resources once it's released! TimClicks (talk) 08:36, 20 July 2018 (UTC)

The reference that Rust only works partially on iOS is outdated

The reference that Rust only works partially on iOS is outdated; according to this link, Rust compiles for all iOS-relevant target architectures and you should be able to use it on every iOS device.

If nobody objects, i'll remove the "(partially)" and update the reference. KizzyCode (talk) 14:21, 8 January 2019 (UTC)

Book of Mozilla

Does anyone know what is meant by "referenced" in the sentence "The language is referenced in The Book of Mozilla as "oxidised metal.""? The way that people use "reference" as a verb to mean almost anything, it's anyone's guess if that means that the Book of Mozilla cites Rust somehow, or that's what it calls Rust wherever it is mentioned, or if that's just a single, oblique mention somewhere in the Book of Mozilla. As it stands, the sentence might as well read "The language is verbed in The Book of Mozilla." — Preceding unsigned comment added by 2601:140:8000:A739:A4CF:846E:82A1:DF9F (talk) 17:12, 8 January 2019 (UTC)

Comparison of traits to C++ concepts

Summary

The current comparison of Rust traits to C++ concepts is incorrect. Should we remove the mention of C++ concepts or expand on them to explain the difference?

A problem with the current comparison

Currently the "Types and polymorphism" section says:

Functions can be given generic parameters, which usually require the generic type to implement a certain trait or traits. Within such a function, the generic value can only be used through those traits. This means that a generic function can be type-checked as soon as it is defined. This is in contrast to C++ templates, which are fundamentally duck typed and cannot be checked until instantiated with concrete types. C++ concepts address the same issue and are expected to be part of C++20 (2020).

But C++ concepts (as currently proposed) are very different from Rust traits, and do not allow for the parameterised function to be type-checked only once.

Rust traits are implemented explicitly, whereas C++ concepts constraints are implicitly met. This means that concept-constrained templates can legally invoke behaviour not defined by the concept. So, the following code compiles in g++ v7.4.0 with flags `--std=c++1z -fconcepts`:

#include <string>

template<typename T>
concept bool Stringable = requires(T a) {
    {a.stringify()} -> std::string;
};

class Cat {
 public:
    std::string stringify() {
        return "meow";
    }

    void pet() {
    }
};

template<Stringable T>
void f(T a) {
    a.pet();
}

int main() {
    f(Cat());
    return 0;
}

The Rust equivalent would not compile:

trait Stringable {
    fn stringify() -> String;
}

struct Cat {
}

impl Cat {
    fn pet() {}
}

impl Stringable for Cat {
    fn stringify() -> String {
        "meow".to_string()
    }
}

fn f<T: Stringable>(a: T) {
    a.pet();  // error[E0599]: no method named `pet` found for type `T` in the current scope
}

fn main() {
    let cat = Cat{};
    f(cat);
}

C++ concept-constrained templates are still only type checked once a concrete instantiation is made -- they just give better, sooner error messages for types that don't comply with the constraint, rather than the long stream of nonsense that failed template instantiations output in C++ without concepts.

Ideas for how to change the article

I think it's quite common for people to think that concepts are the same as traits. They look similar syntactically, and also the realities of them aren't well known because they aren't yet in a standard. But I think it would be worth updating the Wiki here to briefly explain the differences. Either that or we could remove all mention of C++ concepts.

• Pros for mentioning concepts: they are often compared to traits, so it is relevant; we can correct the misinformation that they are the same

• Cons for mentioning concepts: it might take too much space to properly explain and not be worth the distraction

Maybe a separate section (briefly) comparing Rust traits to similar constructs in other languages would be helpful. Perhaps just a few sentences each for some close comparisons:

• Haskell typeclasses: Rust traits are based on these, but Rust does not have higher kinded types, and Rust enforces global uniqueness on trait implementations. This means that there is at most one implementation of a trait for any given type. This is not enforced in Haskell, but it is discouraged to take advantage of this.

• Java interfaces: when Rust traits are used dynamically, they are analagous to Java interfaces, except without the `extend` functionality available in Java.

• C++20 concepts: (insert an edited version of my explanation above)

Does anyone have any thoughts? Lochsh (talk) 19:33, 3 July 2019 (UTC)

References

Split proposed for list of projects using Rust

This list could grow very large, and by itself it is not very encyclopedic for this article. It sees issues with WP:INDISCRIMINATE sometimes. 80.221.159.67 (talk) 07:59, 23 October 2016 (UTC)

It seems to me that this section is only interesting so long as Rust is an up-and-coming language. A quick look at other major programming languages shows that there may be some specific projects mentioned, but not necessarily a link to an attempted comprehensive list. There is a Python list List of Python software, but it seems to me that unless it's generated by a template, it has zero hope of remaining accurate. I would argue for either a) leaving the list here until it becomes unwieldy, b) simply deleting it, or c) creating a template/category page. JustinBlank (talk) 17:27, 1 January 2017 (UTC)

80.221.159.67 JustinBlank It appears no consensus was reached on the above split suggestion, however User:Editor-1 appears to have created the category Category:Software programmed in Rust earlier this year. I have removed the split tag and other section tags which are no longer relevant. {{ping|waddie96}} {talk} 09:28, 27 September 2019 (UTC)

Ada influence Rust dubious?

the citation is relying on a conversation that is only thinking about the use of "Ada pragmas".

"This is a prime candidate for a linter pass. We've talked about such checks before (pragmas, subsets, etc.) along the lines of the pragmas in Ada. I'm in favour."

- https://github.com/rust-lang/rust/issues/1693

So questionable that rust is influenced by Ada. :)

CodyMLar (talk) 19:15, 26 May 2016 (UTC) https://users.rust-lang.org/t/does-rust-have-any-influence-from-ada/5981 — Preceding unsigned comment added by 69.26.74.42 (talk) 22:06, 26 May 2016 (UTC)

I vote to remove mention of Ada as there's no explicit influence from Ada at all, according to the Rust devs themselves. I don't think there'd be any objections to this move. Oecology (talk) 16:30, 30 June 2016 (UTC)

The word of Rust devs isn't really enough to say it didn't have influence. There are many languages which demonstrably borrowed heavily from existing languages, and never mentioned it explicitly, or even denied it. 81.6.34.172 (talk) 21:53, 7 May 2020 (UTC)

Mozilla layoffs and a Rust foundation

Since when are twitter tweets reliable sources for wiki pedia?

Even from people involved in a matter, i.e. non-neutral sources?

Jan Burse (talk) 15:34, 29 January 2021 (UTC)

Misleading/False advertising of Rust's support for IA32 (32 bit) Platforms

The Rust programming language support for IA32 (32 bit) platoforms is almost completely misleading or false advertising.

Rust removed support for CPU's not having SSE2 optimization register within the past year, or was in the process of removing two or more years ago.

The CPU SSE2 optimization register was only fully implented on very late era Intel Pentium 4 CPU's. (See Wikipedia SSE2 article.) Prior to Pentium 4, the SSE2 register was called the MMX CPU register, and to use the MMX register as a SSE2 register would require additional trivial coding. MMX register, again, was only implemented in late era Pentium CPU's.

In brief, Rust programming language seems to have been quietly removing support for the older non-SSE2 CPU's over the past year, quietly subsequently creating havoc within coding and Linux package maintainer social environments, as Rust now only provides SSE2 bootstrap builds. All awhile still advertising IA32 support. A platform not having the SSE2 CPU register executing SSE2 compiled code will usually immediately segfault, and if any error message is given, a very generic error message until digging deeper. --roger (talk) 19:14, 22 February 2021 (UTC)

Rust is not a commercial product therefore it can't exhibit "false advertising." Also, are there 'any' IA32 processors manufactured in the last 15 years that don't support SSE2? War (talk) 06:39, 26 February 2021 (UTC)

Also, until recently Rust could not build 32 bit because of bug in LLVM. That has been fixed. see: https://github.com/rust-lang/rust/pull/81451 War (talk) 00:10, 9 March 2021 (UTC)

Variables assigned multiple times must be marked with the keyword mut

Isn't a mutable variable a tautology?

What is wrong with const x: int = 1; and let x: int = 1;? OttTheTormentor (talk) 21:21, 8 February 2021 (UTC)

No, mutable variable is not a tautology, it is an established word combination in computer science. Another established word combination which looks like a tautology is constant variable.

In Rust, every variable is constant by default (can be made mutable with mut). This is just how the language was defined. Anton.bersh (talk) 11:26, 18 April 2021 (UTC)

Inclusion of rust components as a part of the rust feature set

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion.

A summary of the debate may be found at the bottom of the discussion.

---

A strong part of rust are the components. we have cargo, clippy, rustfmt, rust-docs and more. I would like to raise the question of if these components should be included in the rust wikipedia page

For

• Many of these components are included in the rust source tree (not all)
• A valid thing rust has going for it *is* this ecosystem, It is silly to ignore
• I would argue cargo especially is a part of the core of rust - even if not needed.

Against

• Components are managed by rustup. rustup is developed by rust, but is not "core" (ie a secondary project)
• Technically, the rust lang is just the rustc component - nothing more is needed (ie the lang breaks without it) (although all the components help a lot!)
• Not all components are developed in the core rust source tree

Solutions

• Separate article for rust components
• Inclusion under the features section
• New category.

Discussion

What are your thoughts on this? Scaledish! Talkish? Statish. 01:40, 16 May 2021 (UTC)

Aren't module dependencies handled by cargo? If so, that seems like a compelling reason for including it. I weakly support including the entire ecosystem. Shmuel (Seymour J.) Metz Username:Chatul (talk) 03:48, 16 May 2021 (UTC)

This was what raised the question in the first place for me. I was alarmed to not discover any reference to cargo, and while researching with the intent to include it, I remembered all the other tools. Perhaps the best course of action would first be a study on how other dependency managers are handled in other articles. Upon a brief glance, here is what I discovered

• Python (programming language)'s only reference to the package manager is a link to Pip (package manager)
• Node.js has many references to Npm (software), although Npm has its own article

Next, I looked at Java (programming language) and PHP but I could not find any official connection

I was thinking it was looking bad for the inclusion in this article, and that a new article was needed. Then I thought... Go (programming language), Go and rust are both modern langs, and alas we find Go (programming language)#Tools, very similar to rust components. In my mind, this is a triumph, however I am interested to see other's inputs Scaledish! Talkish? Statish. 15:47, 16 May 2021 (UTC)

Suggest including (invited by the bot) I don't have expertise here but if they are components of crust it's hard to imaging a reason to not include them. Can be brief if that is appropriate. North8000 (talk) 17:30, 16 May 2021 (UTC)

Conclusion: I think it is clear based on Go (programming language) what to do, however if someone has any objections to the inclusion I will hear them out and we can discus moving the new section. Until then, This RFC is closed. Thanks everyone for the input! Scaledish! Talkish? Statish. 18:58, 17 May 2021 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

@Scaledish: Please keep the section to a reasonable length. The entire components set or the Cargo file structure is too much. —Dexxor (talk) 04:56, 18 May 2021 (UTC)

I tried to remove the irrelevant components and will continue doing so as I write. Why do you consider the Cargo section too much, especially considering it is under a minimized by default drop-down? Thanks, Scaledish! Talkish? Statish. 13:09, 18 May 2021 (UTC)

Additionally, I would like to invite @Dexxor: and anyone else to suggest components to include/exclude from the article (Please see the todo list first!). (Unsure if the reply feature mentions, if not see above comment, thanks) Scaledish! Talkish? Statish. 13:33, 18 May 2021 (UTC)

 Done Scaledish! Talkish? Statish. 12:54, 9 June 2021 (UTC)

Add WebAssembly as a target?

Should we add WASM as a listed target? I'm leaning towards no since it's only a "guaranteed to build" target and not a "guaranteed to work" target. 199.58.98.69 (talk) 03:47, 31 July 2019 (UTC)

I'm surprised that WebAssembly isn't included in the list of platforms in this article. Is WebAssembly not a "platform?" Jarble (talk) 16:11, 15 January 2021 (UTC)

The fact that, in your words, it is a "guaranteed to build" target makes me all for inclusion Scaledish! Talkish? Statish. 15:16, 25 May 2021 (UTC)

The "guaranteed to build" part just means that it does not have as much test coverage as `amd64` targets, there are other targets that are "guaranteed to build" that are already on that list. 0xDeadbeef (talk) 17:53, 26 December 2021 (UTC)

Rust is high-level

If the user who says Rust is not high-level wants to create an account and discuss here (or if anyone else wants to voice an opinion), please do. Caleb Stanford (talk) 01:58, 12 November 2021 (UTC)

@Caleb Stanford: I've removed the reference to Rust's "level" from the lede sentence entirely [2]. There's a lot of nuance to what's "high-level" and "low-level" colloquially, and I think adding such a label would just be confusing or controversial. Your edit here adds a better description anyway [3]. If we do add a line about whether Rust is low or high-level, I feel like there should be adequate secondary sources to support that outright. Elephanthunter (talk) 17:06, 23 November 2021 (UTC)

I think that's probably a good idea. Thanks for posting here about it. Caleb Stanford (talk) 19:33, 23 November 2021 (UTC)

Add a Controversy sub-section to Governance?

The rust moderation team seems to have publicly resigned en-masse. This is being further discussed on Reddit here, and is purportedly due to a lack of 'Core Team' oversight. This seems to be a sufficiently big deal to merit a mention, but of course hasn't been resolved yet. — Preceding unsigned comment added by TiredDoc (talk • contribs) 12:28, 23 November 2021 (UTC)

It's possible this should be included, but I'd wait for it to be covered by reliable independent sources (See: WP:RS). Elephanthunter (talk) 16:24, 23 November 2021 (UTC)

I think it should be covered in the article, but not sure how to cover it yet. One thing that these sort of statements ("en masse") overstate though is how many people it was, in this case, 3. Caleb Stanford (talk) 19:46, 23 November 2021 (UTC)

The current governance section is not informative enough for someone to "just" add a section about the recent controversies, since there is currently no information on the Rust teams structure and their relationship with the Rust Foundation at all.0xDeadbeef (talk) 18:08, 26 December 2021 (UTC)

Please add a section about side effects in Rust

Please add a section about side effects in Rust. --VictorPorton (talk) 04:16, 7 August 2020 (UTC)

Such as? War (talk) 07:07, 7 August 2020 (UTC)

I believe he confused this article with the article on rust (on metal) Scaledish! Talkish? Statish. 01:43, 16 May 2021 (UTC)

Do you mean how Rust handles side effect, given that it is a functional programming languge? TimClicks (talk) 00:22, 5 January 2022 (UTC)