Talk:Rust (programming language)/Archive 2

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 4

Archive 5

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: 5 June 2024).

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,"^[1]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 , 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

[1]
Sorry, had to munge the URL to get by the blacklist; I think it's worth preserving the link for this discussion, though.

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

Book of Mozilla

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`^[1]:

#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^[2], and Rust enforces global uniqueness on trait implementations^[3]^[4]. 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.^[5]

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

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

Ada influence Rust dubious?

Mozilla layoffs and a Rust foundation

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

Variables assigned multiple times must be marked with the keyword mut

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)