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

Flattening Rust’s learning curve

corrode.dev

Post reply on HN
Print view View original

391–400 of 405 posts

Re: Flattening Rust’s learning curve

#391

Post by ajross »

pkolaczk wrote: post #380
ajross wrote: post #288

Earlier quoted context omitted.

If the object had a stack-bounded lifetime, the borrow checker would have been able to prove the analysis though. The advice is to clone things it can't, which pretty much requires that it go into the general heap. I'm sure there are some interesting counterexamples, but the situation you're imagining seems kinda academic.

The fact something goes to heap doesn’t necessarily mean it needs more heap allocations. I’ve had it many times that I instantiated a new object on heap and had to pass cloned arguments to it (because it had to own them), yet they ended up as inline fields, so no additional allocations. Happens a lot with Rc / Arc.

Once more: if the compiler can see to inline the object or put it on the stack or replace it with a by-value/in-register copy, then the borrow checker wouldn't have puked to begin with. The advice is very clearly to make heap allocations as a way to evade borrow analysis. I don't see why that's controversial.

Re: Flattening Rust’s learning curve

#392

Post by cmrdporcupine »

int_19h wrote: post #381
cmrdporcupine wrote: post #301

Earlier quoted context omitted.

It's more than that. Rust's value & reference passing semantics are completely different from the way most programmer's have trained their entire lives to think about it. When you pass an argument to a function in Rust, or assign a value into a struct or variable, etc. you are moving it (unless it's Copy). That's extremely different from any other programming language people are used to, where things are broadly pass…

I think sometimes that there's a niche for an alternative syntax for Rust that is generally more verbose (keywords instead of punctuation etc), and which specifically makes this behavior explicit. In other words, for every argument of every call you'd have to write "move" or "copy" and similarly with assignments etc.

RustRover recently added visual indication of the borrowing process within a block of code, which is kind of nice. I think for now it only shows for some cases and only when there's an error? but still you get a highlight of where the borrow happened so you can walk back to it and figure out how to fix it without having the parse through the compile error.

I suspect they'll eventually get a fast and live indicator to the user of where all the references are "going" as they type.

Re: Flattening Rust’s learning curve

#393

Post by bombela »

Animats wrote: post #18

It's like reading "A Discipline of Programming", by Dijkstra. That morality play approach was needed back then, because nobody knew how to think about this stuff. Most explanations of ownership in Rust are far too wordy. See [1]. The core concepts are mostly there, but hidden under all the examples. - Each data object in Rust has exactly one owner. - Ownership can be transferred in ways that preserve the one-owner ru…

I usually teach it by translating it to our physical world by way of an object like a book, which I like to think is intuitive.

I have a book. I own it. I can read it, and write into the margin. Tear the pages off if I want. I can destroy it when I am done with it. It is mine.

I can lend this book in read only to you and many others at the same time. No modifications possible. Nobody can write to it, not even me. But we can all read it. And borrower can lend it recursively in read only to anybody else.

Or I can lend this book exclusively to you in read/write. Nobody but you can write on it. Nobody can read it; not even me; while you borrow it. You could shred the pages, but you cannot destroy the book. You can share it exclusively in read/write to anybody else recursively. When they are done, when you are done, it is back in my hands.

I can give you this book. In this case it is yours to do as you please and you can destroy it.

If you think low level enough, even the shared reference analogy describes what happens in a computer. Nothing is truly parallel when accessing a shared resource. We need to take turns reading the pages. The hardware does this quickly by means of cached copies. And if you don't want people tearing off pages, give then a read only book except for the margins.

Re: Flattening Rust’s learning curve

#394

Post by bombela »

int_19h wrote: post #383
3vidence wrote: post #375

Earlier quoted context omitted.

I still haven't gotten into rust yet, mostly due to time and demand, but, I have been doing a lot of C++ in the past few years. Coming from that background these rules sound fantastic, theres been a lot of work put into c++ the past few years to try and make these things easier to enforce but it's still difficult to do right even with smart pointers.

The main problem is that a lot of things that are correct wrt lifetimes will still not compile because the borrow checker can't prove that they are correct. Even for fairly trivial stuff sometimes, like trees with backlinks.

Rust has succeeded in making us hesitant reaching out to raw pointers. To the point we sometimes forget that we can opt-in into unsafe raw pointers on demand. Unlike C/C++ being opt-in to maybe somewhat safe.

Re: Flattening Rust’s learning curve

#395

Post by boomlinde »

int_19h wrote: post #384
dgfitz wrote: post #296

Earlier quoted context omitted.

I believe you can do that in C pretty easily with a void pointer, someone correct me if I'm mistaken. Should you? Different question entirely.

Pedantically speaking, you can't. You can have a variable that points to an integer 5, and then make it point to a character array "hello\0". But the value of the variable is a pointer in both cases. Curiously enough, this is also true of Python - just less obvious because it doesn't have any variables that aren't pointers, and most operators perform an implicit dereference.

> Pedantically speaking, you can't. You can have a variable that points to an integer 5, and then make it point to a character array "hello\0". But the value of the variable is a pointer in both cases.

Unions may be the better analog here.

> Curiously enough, this is also true of Python - just less obvious because it doesn't have any variables that aren't pointers, and most operators perform an implicit dereference.

That's more like an implementation detail than a quality of the language itself. A JavaScript implementation might do the same. For example, values in V8 are all either pointers to the heap except in the case of small (31-bit) integers, and a less optimized implementation might not even make that distinction and allocate everything on the heap. Similarly, a Python implementation might store SMIs directly where the pointer would be, like V8. PyPy uses both tagged pointers/SMIs and may even allocate registers for values.

Re: Flattening Rust’s learning curve

#396

Post by int_19h »

boomlinde wrote: post #395
int_19h wrote: post #384

Earlier quoted context omitted.

Pedantically speaking, you can't. You can have a variable that points to an integer 5, and then make it point to a character array "hello\0". But the value of the variable is a pointer in both cases. Curiously enough, this is also true of Python - just less obvious because it doesn't have any variables that aren't pointers, and most operators perform an implicit dereference.

> Pedantically speaking, you can't. You can have a variable that points to an integer 5, and then make it point to a character array "hello\0". But the value of the variable is a pointer in both cases. Unions may be the better analog here. > Curiously enough, this is also true of Python - just less obvious because it doesn't have any variables that aren't pointers, and most operators perform an implicit dereference.…

> Unions may be the better analog here.

Tagged unions would be, except they aren't first class in C.

The best analogy here would probably be OCaml polymorphic variants (https://dev.realworldocaml.org/variants.html)

> That's more like an implementation detail than a quality of the language itself.

It is not, though, because - unlike JavaScript - the fact that everything is a reference to object, and each object has a unique identity, is explicitly a part of Python semantics, and this is very visible in many cases. It's easy to observe it for "primitive" types as well simply by inheriting from them.

(OTOH the fact that a given Python implementation might still implement this by using tagged pointers etc is an implementation detail, because it is still required to behave as-if everything was an object).

Re: Flattening Rust’s learning curve

#397

Post by nchmy »

azornathogron wrote: post #251
ants_everywhere wrote: post #36

Earlier quoted context omitted.

I don't think the idiom has in mind any particular curve. I think it's just another case of a misuse becoming idiomatic without any meaning beyond the phrase taken as a unit. E.g. - another think coming -> another thing coming - couldn't care less -> could care less - the proof of the pudding is in the eating -> the proof is in the pudding It's usually not useful to try to determine the meaning of the phrases on the…

(not related to your overall point) > - another think coming -> another thing coming Fascinating. I had never come across this before. I've only ever seen people use "another thing coming".

Likewise. And, yet, I've thought about this for a while now and looked up a bunch of articles and I still think that "thing" is completely - if not more - appropriate.

I fully understand and use "think" as a noun - eg have a think - but when I say "you have another thing coming", there's no expectation or implication that they're going to rethink anything in the future. People often don't do that. Instead, I'm simply implying that reality is going to turn out to be very different (and probably negative/unfavourable for them) than they think/expect.

It's the equivalent of saying "watch out - youve got something else/other than you expect coming to you".

In fact, it even shifts the rethink from sometime in the future to now - "rethink this now, as it's not going to turn out how you expect" And, moreover, it's often said as a final warning "I'm doing you a favour right now by warning you - it's the only generosity you're going to get from me in this matter".

Re: Flattening Rust’s learning curve

#398

Post by nchmy »

tacitusarc wrote: post #99
tacitusarc wrote: post #52

Earlier quoted context omitted.

This is incorrect. A learning curve measures expertise on the x axis and effort on the y axis. Hence the saying "steep learning curve".

Calling it inaccurate was too harsh; my definition only became common usage in 1970, and the original “time vs learning” is still used in academic circles.

Academic circles? That's how it is just used in general. You're the anomaly.

Re: Flattening Rust’s learning curve

#399

Post by boomlinde »

int_19h wrote: post #396
boomlinde wrote: post #395

Earlier quoted context omitted.

> Pedantically speaking, you can't. You can have a variable that points to an integer 5, and then make it point to a character array "hello\0". But the value of the variable is a pointer in both cases. Unions may be the better analog here. > Curiously enough, this is also true of Python - just less obvious because it doesn't have any variables that aren't pointers, and most operators perform an implicit dereference.…

> Unions may be the better analog here. Tagged unions would be, except they aren't first class in C. The best analogy here would probably be OCaml polymorphic variants ( https://dev.realworldocaml.org/variants.html ) > That's more like an implementation detail than a quality of the language itself. It is not, though, because - unlike JavaScript - the fact that everything is a reference to object, and each object has…

> Tagged unions would be, except they aren't first class in C.

For the originally stated example, 'declare a variable, set it to 5 (number), and then set it to the "hello" (string)', a plain union is just fine.

> The best analogy here would probably be OCaml polymorphic variants

It would be, except OCaml is not C.

> It is not, though, because - unlike JavaScript - the fact that everything is a reference to object

Evidently, references and pointers are not the same thing, hence it is an implementation detail whether references correspond to pointers.

> and each object has a unique identity

Which doesn't necessarily have anything to do with their address. It's an opaque value guaranteed to be unique for an object for the duration of its lifetime.

Meanwhile, C pointer values aren't necessarily unique for different objects. For example, a pointer to a struct with one or more fields shares value with a pointer to its first field. It's only once you factor in type that pointers uniquely identify a particular object, so they don't exactly correspond to Python's object identity.

Re: Flattening Rust’s learning curve

#400

Post by tacitusarc »

nchmy wrote: post #398
tacitusarc wrote: post #99

Earlier quoted context omitted.

Calling it inaccurate was too harsh; my definition only became common usage in 1970, and the original “time vs learning” is still used in academic circles.

Academic circles? That's how it is just used in general. You're the anomaly.

To clarify, you believe the common use of “steep learning curve” means easy to learn?
Post reply on HN