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

101–110 of 342 posts

Re: A half-hour to learn Rust

#101

Post by mikewarot »

coldtea wrote: post #85
mikewarot wrote: post #77

Earlier quoted context omitted.

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?

When you write a program, heap variables are allocated using NEW or Malloc... stack variables are local to a procedure or function, the rest are in the Var block before your code, and are neither on the heap, nor the stack. They're global to the program, or the unit.

Re: A half-hour to learn Rust

#102

Post by Aeolun »

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 don’t think you should have much unsafe code as a rust beginner.

Re: A half-hour to learn Rust

#103

Post by mikewarot »

k__ wrote: post #89
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…

if I say

a = 2; b = a; c = a;

There's no pointer in there, just 2.

Re: A half-hour to learn Rust

#104

Post by Aeolun »

pornel wrote: post #91
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.

So the & and * can basically be left out to make ‘self’ a value from the start?

Re: A half-hour to learn Rust

#105

Post by mikewarot »

coldtea wrote: post #79
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...

I've only had a passing acquaintance with C and C++, so I've never used aliases.

I just googled it... why the heck would you copy pointers? That's insane!

In my example, a, b, and c were variables, not pointers.

Re: A half-hour to learn Rust

#107

Post by coldtea »

mikewarot wrote: post #101
coldtea wrote: post #85

Earlier quoted context omitted.

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

When you write a program, heap variables are allocated using NEW or Malloc... stack variables are local to a procedure or function, the rest are in the Var block before your code, and are neither on the heap, nor the stack. They're global to the program, or the unit.

You mean global/static variables?

Yeah, those are not mentioned. It also doesn't mention constant storage...

That said it's not like they're the bread and butter of programming for their lack of mention to be that "odd" as the parent implies.

Re: A half-hour to learn Rust

#108

Post by Aeolun »

mikewarot wrote: post #101
coldtea wrote: post #85

Earlier quoted context omitted.

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

When you write a program, heap variables are allocated using NEW or Malloc... stack variables are local to a procedure or function, the rest are in the Var block before your code, and are neither on the heap, nor the stack. They're global to the program, or the unit.

Wouldn’t that mean they’re on the heap by default? Your program will have to malloc something if they don’t go on the stack.

(My low level knowledge is limited, may be completely wrong)

Re: A half-hour to learn Rust

#109

Post by coldtea »

Aeolun wrote: post #108
mikewarot wrote: post #101

Earlier quoted context omitted.

When you write a program, heap variables are allocated using NEW or Malloc... stack variables are local to a procedure or function, the rest are in the Var block before your code, and are neither on the heap, nor the stack. They're global to the program, or the unit.

Wouldn’t that mean they’re on the heap by default? Your program will have to malloc something if they don’t go on the stack. (My low level knowledge is limited, may be completely wrong)

In some (interpreted mostly) languages they are. Like some also don't have a stack at all.

But in the most common languages, there is special storages for globals, statics, and constants, which is what the grandparent means (e.g. the DATA section).

Post reply on HN