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

71–80 of 342 posts

Re: A half-hour to learn Rust

#71

Post by m-ou-se »

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…

`T: 'a` means that you may keep values of type T around for lifetime 'a, but not that they will. So `T: 'static` means that you may keep values of that type around forever, as they do not refer to anything that doesn't live forever.

So neither `&'a i32` nor `MutexGuard` are 'static (unless 'a is), because you shouldn't keep references like that around longer than the stuff it points to. But i32 by itself satisfies i32: 'static, because it's perfectly fine to keep an i32 around forever. (But that doesn't mean that every i32 will stick around forever.)

Re: A half-hour to learn Rust

#72

Post by mikewarot »

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 tripped me up, Unicode calls these {} curly brackets ?!? (Why did it trip me up? Because on my screen in non-dark mode, { and [ look identical due to my eyesight, and I assumed I was looking at [ because the text said that's what it was... as you get older, you'll understand)

I don't understand why b=a; c=a; I'll get a Rust compiler and start again.

I'm allergic to "macros" as they have had a special place in hell because of their misuse in C... I hope Rust is more sane.

Re: A half-hour to learn Rust

#73

Post by wokwokwok »

kaoD wrote: post #66
wokwokwok wrote: post #41

Earlier quoted context omitted.

I find it very confusing. T: ‘a is T outlives ‘a; but types are not generated at runtime. All types are static; which is to say they are created at compile time and exist for the lifetime of the program. Or does rust generate type variants on the fly at runtime? I didn’t think it did... It is a constraint applied to arguments at compile time ... but r, that’s what I thought anyway.

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 not have and are not related to the 'static lifetime which is “the entire length of the application”.

I accept:

> Type: lifetime means that the type is constrained by the lifetime.

I don't accept the explanation:

> Because 'static means "the lifetime of the whole process". That means that the type is not constrained.

A does not follow from B.

If you want something to mean "A type cannot have references in it" then invent a 'noref lifetime.

'static in this context would mean that all members of T must be 'static, which means that all instances of T must be 'static.

It does not mean that.

I don’t understand why they have the same name; they are not the same thing; it is an example of failure to have orthogonality in the language design in my opinion.

Re: A half-hour to learn Rust

#74

Post by strictfp »

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…

Rust is tricky. Took me about a year to grok decently.

Regarding references, the compiler does flow analysis and tries to enforce a sort of static rwlock semantic on variable level. You either have a single mutable reference xor N readable references to the same variable.

If b is a mutable reference to a, c cannot point to a until b reliquishes the "lock", which happens when b goes out of scope.

Re: A half-hour to learn Rust

#76

Post by kaoD »

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…

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 could be held up to the end of 'static. This does not mean that they're allocated at compile time, it just so happens that static variables (allocated at compile time) are 'static but the causality is reversed.

> If you want something to mean "A type cannot have references in it" then invent a 'noref lifetime.

It can have references in it! As long as they're bound by 'static.

Here's an example: https://play.rust-lang.org/?version=stable&mode=debug&editio...

Re: A half-hour to learn Rust

#77

Post by mikewarot »

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.

Re: A half-hour to learn Rust

#78

Post by [deleted] »

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…

[deleted]

Re: A half-hour to learn Rust

#79

Post by coldtea »

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;

You know how C has a problem with aliases? (multiple variables referencing the same thing)? Which introduce bugs, prevent optimizations, etc?

Well, Rust tries to prevent this, and make more explicit (and known to the compiler) when you do this...

Re: A half-hour to learn Rust

#80

Post by fasterthanlime »

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…

It's definitely a lot to take in, you have the right idea — the compiler is here to help, the diagnostics are wonderful and improving every week thanks to the work of Esteban Kuber and others.

Re macros: try to keep an open mind if you can, C macros and Rust macros are completely different. You can get very far without reaching for them, so don't worry too much!

Post reply on HN