Talk:Rust (programming language)/Archive 4

Archive 1

Archive 2

Archive 3

Archive 4

OO allusions

@War: @Ovinus: About the OO allusions (and there was also a statement about this in the GA review), I disagree that Rust is not OO. Rust is multi-paradigm and can be used for OO. See e.g. here. For that reason, I don't think we should emove mentions of objects, object system, etc. Is there something else we can do to clarify this better for readers? Caleb Stanford (talk) 13:42, 16 July 2022 (UTC)

See also Object-oriented programming, Composition over inheritance. Although I don't think we should call them as "object"s because that is not the correct name, and not used except for trait objects (which are just vtables). 0xDeadbeef 14:38, 16 July 2022 (UTC)

Adam Savage once said that "Every tool's a hammer." This does not mean that it is good idea to describe a tool by its hammer-like properties. As @0xDeadbeef mentioned, Chapter 17 of the Rust docs discusses the issue of how Rust is, and is not, OO. I think we should strive to not confuse the reader into thinking that Rust is a syntactically different C++, when it clearly is not. This came up on the lifetime section concerning "destructors". Again, the Rust docs talk about destructors, but in Rust they are not the same as C++ destructors. Suggesting that they are is inaccurate and confusing to the reader.

I get that with a particular background one thinks of these things from that background. A person that comes from a C++ background will associate features of Rust "as" or "like" various C++ features or C# features or Haskel features, etc. I think we should avoid these associations except where there is a precise and unambiguous correspondence. War (talk) 16:28, 16 July 2022 (UTC)

I confess I'm a bit confused by your response. I didn't say anything about C++. P.S. regarding influences in the lead, do you mind if we keep them in alphabetical order? The source doesn't explicitly state they're in order of how major they are and I am reluctant to make any sort of delineation between them, as we probably won't have good sources to back that up. Caleb Stanford (talk) 20:05, 16 July 2022 (UTC)

As a C++ programmer but not a Rust one, a destructor in Rust looks quite similar to one in C++ and other OO languages, and is aptly named as such. My suggestion would be to state what has been said here: that Rust has some features usually associated with OO languages, but is not regarded as one. Hawkeye7 (discuss) 21:00, 16 July 2022 (UTC)

I may have been sloppy in my edit about RAII by saying "object" rather than "value" (although [1] says "Rust enforces RAII (Resource Acquisition Is Initialization), so whenever an object goes out of scope, its destructor is called and its owned resources are freed"), but, even being agnostic on whether Rust is truly object-oriented, I don't think RAII is necessarily restricted to object-oriented languages, and several sources say Rust very frequently uses that pattern. Ovinus (talk) 21:26, 16 July 2022 (UTC)

@Caleb Stanford 'regarding influences in the lead'. I put them in the order in which they are mentioned in the Rust documentation which seems better than an arbitrary alphabetical ordering. War (talk) 21:30, 16 July 2022 (UTC)

I think we need a 3rd opinion then. The source doesn't say what the order represents, so it's giving more weight to the order than I think it merits. In particular, the current order suggests SML/OCaml had a higher impact on Rust than C++, but the source does not state that explicitly. The point of the alphabetical ordering is to be arbitrary and not assert anything in particular. Caleb Stanford (talk) 02:23, 17 July 2022 (UTC)

Caleb Stanford, third opinions only work for disputes between two people. 0xDeadbeef 03:21, 17 July 2022 (UTC)

I meant about about the major influences point. As far as I saw only War and I weighed in on that, did I miss something? Would you like to weigh in? Caleb Stanford (talk) 03:28, 17 July 2022 (UTC)

Sorry, I didn't read enough context when I posted that comment. Regarding major influences, I think we shouldn't mention any specific languages in the lead at all, instead we could refer to categories/families of languages. 0xDeadbeef 04:24, 17 July 2022 (UTC)

Okay, now we have 3 different opinions lol. Thank you for the input Caleb Stanford (talk) 05:09, 17 July 2022 (UTC)

I disagree with delleting information on anything related to the OOP. Though, it seems like (according to the docs) that Rust isn't supporitng inhertiance in usual sense. This should be covered by the articles. AXONOV (talk) ⚑ 11:31, 2 June 2023 (UTC)

a source for potential use

https://www.infoq.com/news/2019/03/rust-npm-performance/ 0xDeadbeef→∞ (talk to me) 13:54, 19 November 2023 (UTC)

Is infoq.com a reliable source ? Sohom (talk) 16:58, 19 November 2023 (UTC)

I've seen it used on many articles, so presumably yes. I know ZDNet and Ars Technica are considered generally reliable per WP:RSP, but InfoQ hasn't been subject to much discussion. I've seen InfoQ's articles and they are generally pretty good. (much better than self-published sources on Medium and the likes) 0xDeadbeef→∞ (talk to me) 06:31, 20 November 2023 (UTC)

I would personally not include it unless npm themselves publish something about this. The article is basically a summary of a whitepaper written by Rust devs, which is itself a primary source and I cannot find any other (unreliable/reliable) source mentioning this. Sohom (talk) 20:33, 20 November 2023 (UTC)

Added! Caleb Stanford (talk) 20:33, 20 November 2023 (UTC)

rv per my latest comments. Sohom (talk) 20:54, 20 November 2023 (UTC)

is the white paper itself a RS in your view? I think it's a real thing, still looking for other sources. Thanks, Caleb Stanford (talk) 23:24, 21 November 2023 (UTC)

IMO, the InfoQ source should be more reliable than the white paper itself. The white paper is a primary source. 0xDeadbeef→∞ (talk to me) 00:01, 22 November 2023 (UTC)

possible sources for RustConf

I agree with removing the Rust conferences section (WP:NOTDIR)), but I think RustConf alone deserves mention in the community section as the most widely known community gathering. A bit hard to find secondary sources, I have 1 2 or we could use YouTube sources like 3. Might also be worth asking if we want to mention any of the recent RustFoundation related controversies, which got plenty of coverage. Caleb Stanford (talk) 22:06, 29 November 2023 (UTC)

We should definitely try to cover the Rust foundation controversies if there are good sources available. I am less sure about the reliability of the sources that you bring up. The analytics india mag article's author is an AI enthusiast, and the description of crablang (an unofficial, unmaintained fork) makes me think that it leans toward the unreliable side. 0xDeadbeef→∞ (talk to me) 23:58, 29 November 2023 (UTC)

Automated memory management

@Wootery: I'm not sure I understand your recent edit -- the lead stated "without requiring the use of automated memory management techniques", so how are you reading this to imply Rust is hands off? It seems to be stating that Rust is hands on. Perhaps I don't know what you mean by "hands off". Thanks, Caleb Stanford (talk) 19:31, 25 January 2024 (UTC)

Perhaps you're right, my thinking was that it seems to imply that Rust offers memory safety while not offering/requiring automatic memory management features, but Rust's borrower checker presumably counts as an automatic memory management feature, in that it isn't done manually by the programmer. For what it's worth, I see the Rust Book uses phrasing closer to what I'm proposing. Anyway, the next sentence clarifies by introducing the borrower checker, so not much hinges on this. Wootery (talk) 21:42, 25 January 2024 (UTC)

I think I can see Wootery's point. Dropping things at the end of a scope, could be considered an "automated memory management technique". And the current sentence could suggest that automated memory management doesn't exist in rust. 0xDeadbeef→∞ (talk to me) 00:20, 26 January 2024 (UTC)

Ah, thanks for clarifying, I see the issue now. I think the point was to suggest that Rust can (but need not) use reference counting, but I think this was very cryptically stated so we should just move that elsewhere. Edited to hopefully clarify, feel free to edit further. Caleb Stanford (talk) 17:36, 26 January 2024 (UTC)

Closure section

Currently, the closure section throws a parser-specific syntax at the user (and is the only section to that making it somewhat jarring), is there any way we can remove it from the article ? (It seems to be a transclusion of a part of a different article that makes liberal use of the parser syntax, which seems fine). Sohom (talk) 00:42, 11 December 2023 (UTC)

That section isn't placed well. We should to restructure it, by giving it more sources, and some more natural flow. 0xDeadbeef→∞ (talk to me) 14:54, 22 March 2024 (UTC)

FAC preparation

Alright, after working on the article for some time I am optimistic that we would be able to push this to FA, making it the first ever featured article on a programming language. (which would make it featured eventually on the top left of Wikipedia's main page!!) Before we submit it to WP:FAC, here are some things to prepare:

1. We need to address the comments above, there are a number of comments above in #Addressing PR comments as well as one under #Reader comments that are outstanding and still apply. If anyone has a book about Rust that can help expand the article's technical explanations to something that would be more understandable for a general audience please feel free to contribute! (some comments on the books: I've been trying to source with The Rust Programming Language 2021 edition but I couldn't find an ebook online that has the correct page numbers, if anyone can send me one please let me know, I have ebook copies of Rust for Rustaceans published by No Starch Press, Rust in Action by Tim McNamara, and Programming Rust published by O'Reilly if any wants, as those are good sources)
2. We need to convert all the online sources to book sources if possible. I saw some sources using the documentation for the standard library and preferably we should use books instead.
3. After those issues, we're mostly good to go after a thorough read of the FA criteria, going over all sources in the article and seeing if they actually supported the claim, and reading the article to check its prose.

To people watching this page: Please consider helping out! I'm a bit busy, but if more people contribute it will nudge me to contribute more as well. 0xDeadbeef→∞ (talk to me) 13:40, 7 February 2024 (UTC)

For the comment on lifetimes, I have added some examples that should help illustrate it further. There is another gap between talking about lifetimes in generic definitions and to the example with reading configurations, which could use smaller examples to build the knowledge better. 0xDeadbeef→∞ (talk to me) 15:12, 22 March 2024 (UTC)