Jump to content

Talk:Rust (programming language)/Archive 3

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2Archive 3Archive 4

Proposal: Rename "Syntax" section to "Examples"

It demonstrates more than just syntax, including the trait system and polymorphism. Is it okay to rename the section? If so, should I add an invisible anchor to avoid breaking existing section links? Llama Linguist (talk) 20:23, 3 January 2022 (UTC)

I think the bigger question is how to achieve a reasonable separation between this section (Syntax/Examples) and the Features section. Currently, the traits and polymorphism aspect overlaps considerably, and the features section also includes example code (under the macros section) so there isn't a meaningful distinction. It seems too much to provide a thorough overview of syntax features in both sections. What do you see as the difference between these two?
I briefly looked at what other language pages do. C++ makes the reasonable choices to include all of this in one big section called "Language" which includes both a list of features and accompanying code examples. Caleb Stanford (talk) 21:14, 3 January 2022 (UTC)
It's true that there's a decent amount of overlap that would be good to reduce. However, I like being able to see quick overviews of what languages look like before diving into the details of all their features. To me, C++'s big "Language" section feels a bit overwhelming as a reader. Llama Linguist (talk) 21:34, 3 January 2022 (UTC)
I added an example to showcase the if let statement, but a link to the cookbook could be added for further examples. (I haven't made a wiki account, sorry) — Preceding unsigned comment added by 92.21.33.45 (talk) 12:53, 13 February 2022 (UTC)

Null pointers

In the section Syntax, the article says Rust has no null pointers[51] unless dereferencing a null pointer. That doesn't make sense. How can you dereference a null pointer is there are no null pointers? 62.216.5.216 (talk) 12:50, 24 March 2022 (UTC)

Security or (Functional) Safety?

In the section Performance, the term "safety" is used, which is somewhat ambiguous. Obviously this is related to the memory topics, but people reading this which are more used to functional safety, might understand it in the way that features exist like in languages designed for that, e.g. Ada_(programming_language). — Preceding unsigned comment added by Torsknod (talk • contribs) 10:54, 7 April 2022 (UTC)

Rust developers have always been a bit vague about the term safety; when it doesn't mean memory safety, I think it means something like, "it's hard for a user to accidentally mess things up." I'm not sure that's too far away or incompatible from functional safety. Since the passage you mention is a direct quote, it's harder to edit. Do you have a proposed edit or can you clarify what might help the article for you? More discussion of what "safety" means somewhere? Caleb Stanford (talk) 11:58, 7 April 2022 (UTC)

Technical Jargon

70.36.195.225 (talk) added the {{Technical}} template, I will ask them in their user talk to point to potential areas of improvements here. 0xDeadbeef (T C) 02:59, 14 May 2022 (UTC)

I made an edit which attempts to address the template -- let me know if it is an improvement. If there are other offending sentences that I missed, please point them out here! Caleb Stanford (talk) 15:06, 15 May 2022 (UTC)

Name origin

@0xDeadbeef: Sorry about the revert. I really would appreciate that we discuss before removing others' work (or removing any substantial content for that matter).

I'm inclined to agree that the quote is not great, but I don't see a better way to source the name origin. The origin of the name (of the article subject) is centrally relevant to the article, so I dispute WP:Trivia. I included the quote because it's hard to summarize what Hoare appears to be saying without the full context (and some previous summaries in the article were oversimplified). Maybe there's a better source for the origin of the name somewhere? If not, I'd like to keep the quote in some form. Also not sure I understand why it fails WP:Verifiability by modern standards. Caleb Stanford (talk) 17:10, 22 June 2022 (UTC)

@Caleb Stanford, I like to follow WP:BRD instead of WP:0RR. And I doubt if there are any WP:Reliable sources that can tell us about the name origin. It fails verifiability because a reader cannot verify whether the facts are true by looking it up from the source. Reddit is not a reliable source and Wikipedia prefers to use secondary sources if necessary.
An IRC archive service that is known to log IRC messages on the mozilla IRC might make it more authentic, but it is still very far away from being a reliable source. 0xDeadbeef 22:27, 22 June 2022 (UTC)
I like WP:Bold-refine and WP:ROWN (which are not incompatible with WP:BRD) -- just reverting something that someone else added without understanding the problem it was trying to solve threatens WP:AGF.
The only thing that I feel strongly about here is that the article should address the origin of the name. I don't know how to do that, but think it's important to include. A broader point is that WP's policies often fall short of being directly applicable for a modern topic such as Rust, where a good deal of reliable information about the topic isn't in printed textbooks, news media, or academic articles, but rather in more nonstandard mediums such as blog posts, online books, and forums. So I think we need to exercise some discretion about what citations we allow while still trying to put together a reliable, verifiable article. And I don't know how to do that, either, but I wonder if it has been discussed elsewhere. Caleb Stanford (talk) 22:49, 22 June 2022 (UTC)
I don't think a consensus can be reached, I will ask for WP:3O shortly. Courtesy Special:Diff/1094443532 for the content discussed. 0xDeadbeef 23:01, 22 June 2022 (UTC)

3O Response: Social media websites like Reddit are not reliable sources. Any further discussion should occur at WP:RSN. ––FormalDude talk 23:12, 22 June 2022 (UTC)

@Stesmo: I saw your recent edit to the external links section and I'm wondering if you could elaborate on how WP:EL applies here? These are just about the 3 most relevant links related to Rust: the official website, the official repository for the source code / compiler, and the official repository for packages.

Thanks Caleb Stanford (talk) 23:42, 18 June 2022 (UTC)

Looking at WP:ELOFFICIAL WP:ELMIN I think the removal is appropriate. 0xDeadbeef 02:19, 19 June 2022 (UTC)
Is there another location in the article these links could go, such as in the infobox or in a note? I'd like to follow the spirit of the law rather than the letter here. All three have some claim to be the official website of Rust. Caleb Stanford (talk) 03:27, 19 June 2022 (UTC)
@Caleb Stanford:Do note that the github repo points to rust-lang.org and rust-lang.org points to github, so there's no real need to have both links. Crates.io only gets one mention (and of course someone added an external link to it in the body of the article <sigh>) in the entire article and is linked from doc.rust-lang.org. And, of course, search engines exist. For me, the 'spirit of the law' is 'don't link out of Wikipedia except for citations and in these very few instances (and hide those in their very own area at the end of the article)'. Stesmo (talk) 05:29, 23 June 2022 (UTC)

RLS Deprecation

On June 1st 2022, RLS has been officially deprecated in favor of rust-analyzer. Should the mention of RLS be removed? W1keeeee (talk) 07:13, 9 July 2022 (UTC)

Done! And I think you meant July 1. Caleb Stanford (talk) 20:28, 9 July 2022 (UTC)

Thoughts for GAN

@0xDeadbeef: Thought I should give you some thoughts preceding the good article review. I'd recommend a bit more in the Performance section, because one of Rust's main goals is being a systems programming language. Of course we shouldn't put silly stuff like trying to numerically compare Rust's performance to that of other languages, but it should at least be noted that much of what Rust provides are zero-cost abstractions, an extension to what is mentioned in [72]. It's also worth mentioning that inline asm and compiler intrinsics are supported. Anyway, the article actually looks quite good! Ovinus (talk) 21:44, 9 July 2022 (UTC)

Ovinus, Thanks, although you might be applying the criteria for FA here. On WP:GACR it says that it addresses the main aspects of the topic which allows the current omission of specific details of performance. I certainly agree that the section should be improved, but just not as a blocker for GA. 0xDeadbeef 05:52, 10 July 2022 (UTC)
Ovinus Thanks for pointing this out! FWIW, I have made a similar suggestion before, that section definitely needs expansion and I've been meaning to take a look at good sources for doing so. Discussing zero-cost abstraction is a great idea. Caleb Stanford (talk) 03:54, 11 July 2022 (UTC)

Performance

Need help finding a source that mentioned Rusts rendering and packing of struct and enum elements as a performance win. For example, "https://play.rust-lang.org/?version=stable&mode=release&edition=2018" I've been involved in many C/C++ projects that would have benefited substantially in performance had it been part of those languages. For Rust to do this natively is a big win. This should be mentioned in the Performance section, IMHO. War (talk) 19:53, 11 July 2022 (UTC)

War, I didn't know that reordering existed and the source code [1] proved me wrong.. sorry for that edit summary, I will try to find a RS that mentions this.. 0xDeadbeef 05:24, 12 July 2022 (UTC)
War, got one: https://dlnext.acm.org/doi/10.1145/3445814.3446724, although the wording might not be optimal: "While some compilers (e.g., Rust) support structure reordering" Anyone can feel free to put this in, without WP:OR of course. 0xDeadbeef 05:44, 12 July 2022 (UTC)
Maybe undo the revert of my edit and add this as a citation. I dislike repeating myself so someone else will have to do it otherwise.War (talk) 06:00, 12 July 2022 (UTC)
Looks like the content is restored now, thank you both. Btw User:War, do you have a fixed link to the playground demonstration you wanted to share? Would be curious to see it. Caleb Stanford (talk) 14:39, 12 July 2022 (UTC)
sure. Here you go: "https://play.rust-lang.org/?version=stable&mode=release&edition=2018&gist=e34c514f60ff4480d243e14e538213bf"War (talk) 02:46, 13 July 2022 (UTC)
And here's a slight modification to show the offsets. "https://play.rust-lang.org/?version=stable&mode=release&edition=2018&gist=bac69353943fcdfea177098a0fdad5ba" War (talk) 03:33, 13 July 2022 (UTC)

Revisiting the separation between #Syntax and semantics and #Features

Thanks to User:0xDeadbeef for all the work on the article :) Regarding this edit, I am wondering if we can revisit the distinction between these two sections, as I'm not really clear on it and that will help clarify where things like the Ownership discussion belong. What aspects of Rust should be described in syntax, and which in features? Should Features omit code examples, or can it also contain code?

Caleb Stanford (talk) 16:17, 14 July 2022 (UTC)

"2010 General-purpose programming language"

@Sandstein: Is there a reason you put 2010 in front of the short description? Carbon doesn't have one. Also I just think that all short descriptions saying "general-purpose programming language" on all programming languages I came up with is pretty unhelpful to readers. 0xDeadbeef 15:44, 18 September 2022 (UTC)

@0xDeadbeef, per WP:SDDATES, dates can be included to enhance the description; since the title already tells us it's an operating language, there's little else to add. Perhaps no short description at all would be better. Sandstein 15:59, 18 September 2022 (UTC)
I've changed it to "General-purpose programming language" in line with similar articles like C (programming language) and C++. Rationale: "Memory-safe" is too specific, imo. Although that's a selling point, it could be applied to, say, any GCed language. But including a year does not make sense to me; that's more appropriate for contextualizing more ephemeral topics like video games. Ovinus (talk) 16:37, 18 September 2022 (UTC)
+1 for "general-purpose programming language" in light of the other PL articles. Caleb Stanford (talk) 00:11, 20 September 2022 (UTC)

explicit/implicit built-ins

@0xDeadbeef: I don't think note 3 is quite accurate. Int literals are a bit special in that the type does not need to be specified, even when it can't be inferred; the compiler just chooses an interpretation anyway. E.g. this works: 

   fn main() {
       println!("Hello, world!");
       println!("{}", 3);
   }

Caleb Stanford (talk) 17:46, 14 October 2022 (UTC)

I was talking about how
let a: u8 = 1;
causes the literal to be inferred as having an u8 type. If there is a way to phrase this clearer, then feel free to improve it. 0xDeadbeef→∞ 17:49, 14 October 2022 (UTC)
Well my problem is that the current draft now is both inaccurate and doesn't address implicit types. I would like to bring the implicit types back (which you deleted), do you object to that? We could leave a (reworded) note on the explicit types if you prefer. Caleb Stanford (talk) 19:53, 14 October 2022 (UTC)
No objections. 0xDeadbeef→∞ 02:48, 15 October 2022 (UTC)

What about the C influence in rust ?

I'm still learning rust, but for me the C programming language in it is undeniable. For instance, presentations introducing rust for C programmers can cover vast portions of the language -- for instance the fact that it is object-based, and not object-oriented.

No doubt, rust is much more than its C inheritance: there is generic programming and some concepts from functional programming languages. But for me it's clear that the C architecture prevailing in rust allows it to generate fast machine code. 152.250.81.206 (talk) 15:46, 8 April 2023 (UTC)

If you can find a reference for this addition, go for it! appendix only lists C++. Caleb Stanford (talk) 20:06, 9 April 2023 (UTC)

Weaknesses / Disadvantages

When reading the page, I was quite surprised that there seems to be no section concerning rust's weaknesses. While I don't want to get into many specifics here, it is quite obvious that rust, like any other programming languages, does have some weaknesses, such as:

- painfully slow compile compared to C/C++ - appalling language stability

Especially the latter clearly puts rust in the category of toy/experimental languages. In order to compile firefox from source for instance, I have to upgrade rust about three times a year. It seems there is absolutely no serious effort of even a mid-term stabilization of the language. Timtas (talk) 04:19, 23 September 2022 (UTC)

Not to be pedantic, but a Wikipedia article should not be a list of strengths and weaknesses per se. If there are statements in the article that read as either endorsements or criticisms, they should be edited to a neutral point of view!
Compile times would be awesome to mention under the "Performance" section if we can add a good source for that. On the language stability side, the current article organization doesn't offer an obvious place to put it, but we do have the Binstock quote under History:
According to Binstock, while Rust was "widely viewed as a remarkably elegant language", adoption slowed because it repeatedly changed between versions.
Would be happy to see mentions of major/breaking changes in the History section, and/or comments about Rust adoption. Caleb Stanford (talk) 04:51, 23 September 2022 (UTC)
Hi @Timtas: do you have a reliable source for the slow compile times? As for stability, I thought the developers made sure to not make breaking changes. The problem with "compared to C/C++" is that you have to specify what compiler you are using. Is it GCC? MSVC? Or Clang? A fair comparison would be Clang since that would factor out the LLVM optimization times. 0xDeadbeef 06:00, 23 September 2022 (UTC)
No, I have no reliable source for the slow compile times, just my personal expierience when compiling firefox.
As for language stability, it might well be that there are not many breaking changes, but firefox forces me to upgrade rustc about two or three times a year, due to language changes. Timtas (talk) 10:22, 23 September 2022 (UTC)
Compiling large projects uses a lot of optimizations such as link-time optimization that consume a lot of time. This isn't necessarily caused by the Rust compiler. The issue with constantly bumped MSRVs (Minimum supported Rust versions) is that Rust does not need to bump a year-based version code in order to add new features to the language. Rust is still a fairly new language so I would expect even big projects to update their Rust versions once in a while to get benefits from new features. 0xDeadbeef 14:21, 23 September 2022 (UTC)
Honestly I think the page is fairly neutral, certainly compared to most Internet articles I've seen. This issue is that we need reliable sources to give criticism, and they don't give much. A disillusioned Rustacean (and friend of mine) gave me some other criticisms, but I could not find a reliable source for any of them (e.g. unpleasant dynamic dispatch, cultish community). Ovinus (talk) 15:13, 23 September 2022 (UTC)
I couldn't find reliable sources for Rust's slow compile times, but many Rust developers think there is room for improvement as these two recent articles show: Rust Survey 2021 Results and Ten challenges for Rust. —Dexxor (talk) 07:10, 24 September 2022 (UTC)
Based on what I've read from a variety of sources (mostly on Discord and random discussions on the internet, I can try to find web-based sources if reminded to do so), the slow compile times are mainly due to Rust performing things like safety checks during compile time, and linking of libraries. Linking, in particular, is single threaded, due to the use of lld, which I've found to be helped with the mold linker, a highly parallelized drop-in replacement.
It could be useful to mention how C and related languages perform very little memory safety checks during runtime, which can often result in a crash during a simple hello world. The behavior was since changed so that a bare hello world wouldn't cause issues, but it's worth mentioning similar situations. Orowith2os (talk) 19:12, 17 April 2023 (UTC)

Some references to use

[2] [3] [4] [5] [6] 0xDeadbeef→∞ (talk to me) 05:49, 7 May 2023 (UTC)

Rust is not a high-level language

Rust, like C and C++ might have structured syntax, but that is different to being a high-level language. These are low-level system languages and should not be used for general application programming, or even higher-level OS programming. That results in poor separation of concerns — something C is very bad at. Ian.joyner (talk) 19:56, 13 May 2023 (UTC)

Your second sentence is false as plenty of people use Rust for both general application programming and higher-level OS programming. Much of the confusion stems from the fact the language offers both high-level features (e.g., iterators and traits) and low-level features (e.g., inline assembly and `Drop` implementations); the latter are quite rare in real-world code. On the other hand, from an architecture and hardware perspective both C and Rust are referred to as high-level. Anyway, I think it's better to avoid the whole debate about the term; it certainly doesn't need mentioning in the first sentence of the article, and doesn't add much to "general-purpose", so I removed it. Caleb Stanford (talk) 02:27, 14 May 2023 (UTC)

No trans representation?

I am disappointed at the lack of even a mention of the trans community since Rust is the most popular language in the trans community. I honestly feel like that's prejudicial. Vedisassanti (talk) 08:48, 16 May 2023 (UTC)

I cannot find reliable sources that bring up the connection between Rust's userbase and transgender people, and we cannot add these claims if there are no reliable sources to suggest so. 0xDeadbeef→∞ (talk to me) 12:02, 16 May 2023 (UTC)

Other ideas

Thanks to everyone, especially deadbeef, for all the article improvement! Some ideas for further improvement (sorry that I missed the peer review!) that I'd like to get others' thoughts on, because frankly I only have cursory knowledge of Rust:

  • A little confused on "1 (Inferred type)" being in the byte row. Aren't integer literals implicitly i32 unless they're too big?
  • Some stuff on multithreading, and how restricting values to have only one mutable reference at one time prevents data races, etc., since that's what makes Rust powerful for concurrency.
  • More on unsafe code and the low-level stuff. The book I have has a fair amount dedicated to signals, interrupts, and all that, and it's good to emphasize that Rust can be used for that. But there's obviously a lot that could be said, so I'm not sure how much is WP:DUE. Also, we should mention that C-style undefined behavior is still a thing, just less pervasive.
  • In a similar vein, the fact that a+b where a,b are integers panics on overflow without optimization, and is ignored otherwise, and also the existence of wrapping_add and friends. I think that's a good example of an easily sourcable difference between Rust and C.
  • Lack of standardization/formal specification, which is a big difference between Rust and C, and just the fact that Rust is, for most intents and purposes, a monolithic single implementation. Alas, I can't find RS on this topic as I suspect it's a low priority. There is some interesting stuff about formal program verification, e.g. [7] Ovinus (talk) 22:16, 16 July 2022 (UTC)
I am currently looking into learning more unsafe Rust so that I can write some stuff on raw pointers and the like. It might also be useful for multithreading, since unsafe allows data races (multiple mutable references with raw pointers). It's not too high of a priority though, so don't expect any changes yet. I still have to twist my experience into a blog post so I can see if I can explain it in a simple way. Orowith2os (talk) 15:50, 30 May 2023 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Talk:Rust_(programming_language)/Archive_3&oldid=1226457589"