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

A half-hour to learn Rust

fasterthanli.me

Post reply on HN
Print view View original

91–100 of 342 posts

Re: A half-hour to learn Rust

#91

Post by pornel »

dmurray wrote: post #87

Great article. I've never used Rust before so I'm exactly the target audience. I first got tripped up around > Trait methods can also take self by reference or mutable reference: impl std::clone::Clone for Number { fn clone(&self) -> Self { Self { ..*self } } } What's the asterisk doing in this code? I guess it's destructuring the struct somehow, but I don't see that syntax elsewhere: destructuring was introduced but…

It is dereferencing. It changes `&self` to `self`. The `..` operator wants a value, not a reference.

Re: A half-hour to learn Rust

#92

Post by aliceryhl »

mikewarot wrote: post #72

I was a complete Nube an hour ago... I understand info from Nubes has special value, so I'll be as explicit as I can. I must be slow, being an old fart... I've been at it for 53 minutes and got about 1/2 way before all the questions in my brain stacked up to "full". I'd add a recommendation at the top of this to have a Rust compiler handy. {} were called braces when I learned programming, [] were brackets... this tri…

Regarding a getting used up, the Rust compiler enforces a single-ownership principle where all values must have a single owner. If you move ownership of a to b, you cannot use a anymore as it no longer has ownership of the value.

The only exception to the above is if a type "is Copy". This means that values of this type can be copied very cheaply, and in this case the compiler will allow you to use it multiple times, which is implemented by it being duplicated on each use.

As for macros, they are nothing like C macros.

Re: A half-hour to learn Rust

#93

Post by fasterthanlime »

coldtea wrote: post #82
timhigins wrote: post #2

A half-hour to learn Rust Jan 27, 2020 · 51 minute read · rust maybe the site's reading time estimator is broken? sarcasm intended. But seriously, it is good to have people writing things like this.

> maybe the site's reading time estimator is broken No, it's just made for prose, not tutorials.

Yep, code is a lot of "words" which throws off the estimate. I need to address this, but I don't think completely ignoring code blocks is really the solution there.

Re: A half-hour to learn Rust

#94

Post by AsyncAwait »

wokwokwok wrote: post #81
kaoD wrote: post #76

Earlier quoted context omitted.

Sorry, I probably edited my comment while you were replying and added a couple links. Check misconception 2 here, I think it addresses your point. https://github.com/pretzelhammer/rust-blog/blob/master/posts... EDIT to your edit: > 'static in this context would mean that all instances of T must be 'static. You mean in T: 'static? No. It means that any instance passed as type T must be bound by 'static and therefore c…

Oh, I've read that. I just maintain that the word 'static is being overloaded here to mean multiple different things. 'static is not the "lifetime of the entire application" when it is used in the context of T: 'static. > It can have references in it! As long as they're bound by 'static. :) ...but it can also have values in it which are not 'static. So is T: 'static, or not? It's arbitrary semantics; ...but my take o…

> ...but it can also have values in it which are not 'static.

I don't think that's right. It can only have references which live at least as long as 'static does (or longer, but 'static is the longest so...)

Re: A half-hour to learn Rust

#95

Post by pornel »

wokwokwok wrote: post #32

> There is a special lifetime, named 'static, which is valid for the entire program's lifetime. I've heard this many times before, but as the guide[1] says: "You might encounter it in two situations... Both are related but subtly different and this is a common source for confusion when learning Rust." 'static means different things for references and trait objects. ie. 'a: 'static --> reference with lifetime 'a lives…

The missing information here is that lifetimes don't apply at all to types that don't contain any borrowed references (such as `i32`, or self-contained `String`).

So `T: 'static` doesn't require types to live for the entire duration of the program. It requires borrows if there are any to be valid for that long. If there are no borrows involved, then 'static is ignored.

In practice `T: 'static` should be understood as "all temporary references are forbidden here".

Re: A half-hour to learn Rust

#96

Post by fasterthanlime »

internet_user wrote: post #24
timhigins wrote: post #2

A half-hour to learn Rust Jan 27, 2020 · 51 minute read · rust maybe the site's reading time estimator is broken? sarcasm intended. But seriously, it is good to have people writing things like this.

half-hours is only the compilation time.

Sarcasm aside, the Rust compiler has gotten a lot faster (and parallelizes better) over the last year thanks to Nicolas Nethercote and others.

Another thing few people realize is that the "incremental" compilation mode that's the default for debug builds can also be enabled for release builds!

In CI, something like sccache can help a lot (using the GCS or S3 backend). It makes GitHub Actions' two-core limit almost bearable. Almost.

Re: A half-hour to learn Rust

#97

Post by kaoD »

wokwokwok wrote: post #81
kaoD wrote: post #76

Earlier quoted context omitted.

Sorry, I probably edited my comment while you were replying and added a couple links. Check misconception 2 here, I think it addresses your point. https://github.com/pretzelhammer/rust-blog/blob/master/posts... EDIT to your edit: > 'static in this context would mean that all instances of T must be 'static. You mean in T: 'static? No. It means that any instance passed as type T must be bound by 'static and therefore c…

Oh, I've read that. I just maintain that the word 'static is being overloaded here to mean multiple different things. 'static is not the "lifetime of the entire application" when it is used in the context of T: 'static. > It can have references in it! As long as they're bound by 'static. :) ...but it can also have values in it which are not 'static. So is T: 'static, or not? It's arbitrary semantics; ...but my take o…

> 'static is not the "lifetime of the entire application" when it is used in the context of T: 'static.

Yes it is.

T: 'static means T can live up to the end of the "lifetime of the entire application".

> ...but it can also have values in it which are not 'static.

I don't follow. Values are indeed bound by 'static. If they weren't we wouldn't be able to pass values to other threads (which can potentially last as long as our application's main thread).

> 'static is not the "lifetime of the entire application" when it is used in the context of T: 'static.

It is. Any owned instance without non-'static references inside can live up to the "lifetime of the entire application". You might drop them earlier if you wanted to, but you don't have to since it can live up to the "lifetime of the entire application" and therefore can be passed for example into a thread that can hold the value up to the end of the "lifetime of the entire application".

Any owned value can be held indefinitely as long as the program is running.

I'm taking a guess here: you mean that values' lifetimes can be constrained (I guess you mean by dropping the actual value). But it's the owner the one that ended it earlier, not the caller (where 'static applied). You will never be able to have an owned value with a lifetime shorter than 'static without dropping it and, if you drop it, you cannot pass it anywhere. Hence why any owned type that is passed is, by definition, bound by 'static.

> ...but my take on it is:

> - IF you take "x is 'static" as meaning the "X is valid for entire lifetime of the application"

> then if:

> - x: &'static 'is static' and must be valid for the entire lifetime of the application.

> I would expect:

> - x: T + 'static 'is static' and must be valid for the entire lifetime of the application.

Your expectations are correct and that's what it is. Just replace "must be valid" with "can live up to".

That's why you need to pass T: 'static to threads, because a separate thread needs something to hold up to the end of the application since a thread can potentially never end.

https://doc.rust-lang.org/std/thread/fn.spawn.html

Re: A half-hour to learn Rust

#98

Post by kaoD »

AsyncAwait wrote: post #94
wokwokwok wrote: post #81

Earlier quoted context omitted.

Oh, I've read that. I just maintain that the word 'static is being overloaded here to mean multiple different things. 'static is not the "lifetime of the entire application" when it is used in the context of T: 'static. > It can have references in it! As long as they're bound by 'static. :) ...but it can also have values in it which are not 'static. So is T: 'static, or not? It's arbitrary semantics; ...but my take o…

> ...but it can also have values in it which are not 'static. I don't think that's right. It can only have references which live at least as long as 'static does (or longer, but 'static is the longest so...)

I think he means owned values (notice he didn't say "other references") But actually... owned values are bound by 'static!

Re: A half-hour to learn Rust

#99

Post by st1x7 »

dmurray wrote: post #87

Great article. I've never used Rust before so I'm exactly the target audience. I first got tripped up around > Trait methods can also take self by reference or mutable reference: impl std::clone::Clone for Number { fn clone(&self) -> Self { Self { ..*self } } } What's the asterisk doing in this code? I guess it's destructuring the struct somehow, but I don't see that syntax elsewhere: destructuring was introduced but…

I also find some of the syntax peciliarities and their combinations difficult to look up. In addition to & and *, there's question marks, dots, double dots, square/round/triangle brackets, empty parentheses and apostrophes all over the place and it makes it really difficult to deconstruct what's happening in a block of code.
Post reply on HN