Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust Language Cheat Sheet

cheats.rs

Post reply on HN
Print view View original

31–40 of 65 posts

Re: Rust Language Cheat Sheet

#31

Post by arnsholt »

masklinn wrote: post #18
excessive wrote: post #9

Earlier quoted context omitted.

Scheme has to fall somewhere between Smalltalk and Forth for quantity of syntax too. To me, these are the prettiest languages.

I didn't mention lisps because I'm never sure how to classify "built-in" special forms: should they be considered normal names and thus omitted from a syntactic overview or should they be considered keywords and included? On the one hand they usually have non-normal evaluation and custom mini-languages, on the other so do most macros otherwise you'd just use a function. But yeah, these are the sort of languages I thi…

> small languages which reach "smallness" by giving access to a limited set of extremely powerful constructs

That's one of the things I really loved when working in Smalltalk: the language gives you all of the building blocks necessary to build more or less then entire standard library, which makes it extremely simple to implement custom control structures for your application. That, and the fact that you're programming directly in your running application of course.

Re: Rust Language Cheat Sheet

#32

Post by steveklabnik »

asdkhadsj wrote: post #29
masklinn wrote: post #21

Earlier quoted context omitted.

Technically here the `;` is for the `let`, which is a statement, not for the match expression within it. The braces are part of the match, not of the let. So the let doesn't end with a block, and thus requires a semicolon.

Weird, I thought it was just something like "If it's an expression, use a semicolon otherwise you're returning it". Yet everyone here is making a distinction between blocks and not-blocks. Is "my rule" better? Furthermore, if you say the semicolon is for the let I think it misleads people. Eg if you do `match foo { .. }`, with no let and no semicolon (which is what that rule would suggest) , you're actually returning…

> Weird, I thought it was just something like "If it's an expression, use a semicolon otherwise you're returning it".

This is a common misconception, but it isn't true.

Rust is an expression-oriented language. This means that most things are expressions, and evaluate to some kind of value. However, there are also statements. "Item declarations" (stuff like defining structs, etc) and let statements are the two most common kinds of statements. However, there's also an "expression statement", where you can take any expression, add ; to it, and it becomes a statement rather than an expression.

A block has the following grammar:

  BlockExpression :
     {
        InnerAttribute*
        Statements?
     }

  Statements :
        Statement+
     | Statement+ ExpressionWithoutBlock
     | ExpressionWithoutBlock
A block is made of (leaving some things out for simplicity) zero or more statements, where statements is either one or more statements, one or more statements and an expression, or an expression.

Note that blocks are themselves expressions, and so evaluate to a value. The only way that you get "no semicolon for return" is when the expression is in this tail position, when its value is the value of the whole block.

... does that make sense? Perusing https://doc.rust-lang.org/reference/statements-and-expressio... might help.

Re: Rust Language Cheat Sheet

#34

Post by steveklabnik »

indemnity wrote: post #23
quietbritishjim wrote: post #10

Earlier quoted context omitted.

I know everyone says how good Rust's documentation is but I tried learning Rust with The Rust Book and found it frustrating: too long and wordy on the easy bits and without useful insight on the hard bits. I ended up buying Programming Rust by Jim Blandy [0] on a recommendation from HN comments and found it must easier to learn from. I'm already familiar with several other languages, which that book assumes, so your…

You’re not alone. I found the Rust book very hard going, whereas Programming Rust was just the right amount of rigor and interesting examples for me.

This is why I'm glad we have both; I don't think one resource could ever satisfy everyone. Pumped to see Rust in Action getting closer to publication too!

Re: Rust Language Cheat Sheet

#35

Post by masklinn »

posixplz wrote: post #30
asdkhadsj wrote: post #29

Earlier quoted context omitted.

Weird, I thought it was just something like "If it's an expression, use a semicolon otherwise you're returning it". Yet everyone here is making a distinction between blocks and not-blocks. Is "my rule" better? Furthermore, if you say the semicolon is for the let I think it misleads people. Eg if you do `match foo { .. }`, with no let and no semicolon (which is what that rule would suggest) , you're actually returning…

You’re correct. Other folks seem to be using non-Rust mental models for semicolons.

No they're not, see steve's explanation above.

Putting a semicolon after an expression makes it into a statement, which are unit-valued, which is why the expression's value gets suppressed. It's a subset of "statements not ending with blocks" (since an expression-statement doesn't take a statement-block even if the expression itself has one).

Re: Rust Language Cheat Sheet

#36

Post by asdkhadsj »

steveklabnik wrote: post #32
asdkhadsj wrote: post #29

Earlier quoted context omitted.

Weird, I thought it was just something like "If it's an expression, use a semicolon otherwise you're returning it". Yet everyone here is making a distinction between blocks and not-blocks. Is "my rule" better? Furthermore, if you say the semicolon is for the let I think it misleads people. Eg if you do `match foo { .. }`, with no let and no semicolon (which is what that rule would suggest) , you're actually returning…

> Weird, I thought it was just something like "If it's an expression, use a semicolon otherwise you're returning it". This is a common misconception, but it isn't true. Rust is an expression-oriented language. This means that most things are expressions, and evaluate to some kind of value. However, there are also statements. "Item declarations" (stuff like defining structs, etc) and let statements are the two most co…

TBH I thought it made sense, but I'm still confused on everyone elses description lol.

I feel like what you said is what I said, but with more accuracy and depth. Eg, if my block was:

  {
    foo();
    bar()
    baz();
  }
My statement holds true, no? It's obviously a syntax problem, since I'm trying to define a statement after I define an expression (which would be trying to execute code after a return, effectively).

So.. I'm not arguing (I trust you to be right lol), but I struggle to understand which part of my statement is inaccurate, beyond the simplifications/etc at least.

To word it differently; I still feel what I said..

> If it's an expression, use a semicolon otherwise you're returning it

seems more accurate as a mental cheatsheet than:

> no semicolons after things that use {}, semicolons after everything else.

Since {}'s can so often result in a value returning, defaulting to not using semicolons just because it's a {} seems odd. I would think focusing on if it's an expression would be easier to understand, no?

Appreciate your time as always Steve :)

Re: Rust Language Cheat Sheet

#37

Post by alexbanks »

nmca wrote: post #6

The explanation of lifetimes linked here is really great - I think this goes a little further than just a cheat sheet. Seems to be more like excellent Clif notes.

Lifetimes are about where I bowed out of Rust. I haven't worked with C++ before, or really ever thought about borrowing or lifetimes, so it never really clicked in my head. What's worse is the Rust community's desire to remind you to "Just read the book". Maybe this would be a worthwhile read to get back into it?

Re: Rust Language Cheat Sheet

#39

Post by asdkhadsj »

masklinn wrote: post #35
posixplz wrote: post #30

Earlier quoted context omitted.

You’re correct. Other folks seem to be using non-Rust mental models for semicolons.

No they're not, see steve's explanation above. Putting a semicolon after an expression makes it into a statement, which are unit-valued, which is why the expression's value gets suppressed. It's a subset of "statements not ending with blocks" (since an expression-statement doesn't take a statement-block even if the expression itself has one).

But my comment was in reply to:

> no semicolons after things that use {}, semicolons after everything else.

Which seems fundamentally flawed for a cheatsheet. Unless you never intend to return anything with a bracket, I guess.

Re: Rust Language Cheat Sheet

#40

Post by steveklabnik »

asdkhadsj wrote: post #36
steveklabnik wrote: post #32

Earlier quoted context omitted.

> Weird, I thought it was just something like "If it's an expression, use a semicolon otherwise you're returning it". This is a common misconception, but it isn't true. Rust is an expression-oriented language. This means that most things are expressions, and evaluate to some kind of value. However, there are also statements. "Item declarations" (stuff like defining structs, etc) and let statements are the two most co…

TBH I thought it made sense, but I'm still confused on everyone elses description lol. I feel like what you said is what I said, but with more accuracy and depth. Eg, if my block was: { foo(); bar() baz(); } My statement holds true, no? It's obviously a syntax problem, since I'm trying to define a statement after I define an expression (which would be trying to execute code after a return, effectively) . So.. I'm not…

It is not 100% clear what specifically you're saying to me, to be honest. All I know is, that in the code above, if you expect bar() to return its value from the block, your mental model of how this stuff works is incorrect.

To be honest, my mental model of all of this is "write code, fix it when the compiler complains"; I rarely think about semicolons, and cargo fmt will remove extraneous ones, so it's sometimes hard for me to go anywhere between "these are the rules of the grammar" and "don't think about it at all". My failing, not yours :)

Post reply on HN