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

81–90 of 342 posts

Re: A half-hour to learn Rust

#81

Post by wokwokwok »

kaoD wrote: post #76
wokwokwok wrote: post #73

Earlier quoted context omitted.

You misunderstand; what confuses me is how 'static can mean the same thing in both of these contexts. T: 'static does not mean the references in T must exist for the lifetime of the application. Ie. the lifetime constraint on T isn’t the same 'static from &'static where the reference must life for the entire lifetime of the application. Types are static. T: 'static applies to instances at runtime. These instances do…

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 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.

I'm happy to agree that's not what it does mean, what I'm saying is that it is inconsistent for it not to mean that.

Re: A half-hour to learn Rust

#82

Post by coldtea »

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.

Re: A half-hour to learn Rust

#83

Post by coldtea »

Fannon wrote: post #47
keyle wrote: post #29

Earlier quoted context omitted.

Programmers don't read, they skim in half the time, then auto-complete in their mind with false assumptions!

Is there a name for this behavior? Sounds like something that is categorized as a cognitive bias? I'm confident that this does not only apply to programmers :)

It's the cognitive bias cognitive bias (the idea that every random mistaken behavior can be categorized as a congnitive bias).

Re: A half-hour to learn Rust

#84

Post by fasterthanlime »

tgv wrote: post #19
Animats wrote: post #15

That is the best article on Rust I've ever seen. Better than the Rust book. I've been saying that Rust needed a book that wasn't written by the designers of the language, who are too close to it. Now we have one.

But it only covers the very basics. Disclaimer: I've only scrolled through it, but the code snippets are all small. It does show an admirable amount of Rust's syntax, but it's not very discoverable, whereas the book is reasonably well structured (although not for novices, who have forgotten a specific term). The link also doesn't deal with larger programs: there's not an Rc on the page, let alone something like an Ar…

I have a lot of Rust articles[1] that go into a lot more depth. They're mostly adventures though, we learn about ICMP, ELF, file systems etc.

Some love that style (the detours, the stream of consciousness) and some can't stand it. The Rust book is excellent, and a completely different style — they're complementary!

[1]: https://fasterthanli.me/tags/rust

Re: A half-hour to learn Rust

#85

Post by coldtea »

mikewarot wrote: post #77
mrlonglong wrote: post #5

It only took me a couple of hours to port one of my old C programs, an utility to produce a hexadecimal and ASCII dump to Rust. The Borrow checker didn't even faze me. All I needed was plenty of Google-fu and my coding skills. JetBrains CLion and git are also very useful tools.

The first I'm hearing of the "borrow checker"... so I started reading this https://blog.logrocket.com/introducing-the-rust-borrow-check... , and I got to the part where it says "Your programs have access to two kinds of memory where it can store values: the stack and the heap." They left out variables, which is odd.

How are variables not in either the stack or the heap?

Re: A half-hour to learn Rust

#87

Post by dmurray »

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 looked like it worked without the star. Alternatively, it's dereferencing the reference, but that seems less likely.

Re: A half-hour to learn Rust

#89

Post by k__ »

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…

"I don't understand why b=a; c=a;

Had the same issue a few months ago.

The pointer can only be referenced by one variable at a time.

If you "move" the pointer from a to b then a is figuratively "used up" because a is now blocked from doing anything with the pointer anymore.

I guess, for Rust itself the pointer is still referenced by a, Rust just blocks you from using it. But thinking you moved it to another variable helped me a bit.

Re: A half-hour to learn Rust

#90

Post by AsyncAwait »

wokwokwok wrote: post #73
kaoD wrote: post #66

Earlier quoted context omitted.

Types are not generated at runtime, lifetimes are types (although they cannot be constructed). T and T are different types altogether (although, being generic, they can resolve to the same type if 'a == 'b, but it's not required). All this happens at compile time. When you say T: 'a you say that T is a subtype of 'a hence it lives longer. https://doc.rust-lang.org/nomicon/subtyping.html Maybe you're being confused by…

You misunderstand; what confuses me is how 'static can mean the same thing in both of these contexts. T: 'static does not mean the references in T must exist for the lifetime of the application. Ie. the lifetime constraint on T isn’t the same 'static from &'static where the reference must life for the entire lifetime of the application. Types are static. T: 'static applies to instances at runtime. These instances do…

> T: 'static does not mean the references in T must exist for the lifetime of the application.

It means that T does not have non static references, so it is not a requirement that it lives for the lifetime of the application but can do so.

Post reply on HN