Talk:Rust (programming language)/Archive 2

Archive 1

Archive 2

Archive 3

Archive 4

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,"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