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

Why Rust's ownership/borrowing is hard

softwaremaniacs.org

Post reply on HN
Print view View original

31–40 of 67 posts

Re: Why Rust's ownership/borrowing is hard

#31

Post by KMag »

klodolph wrote: post #26
jerf wrote: post #14

"Rust's ownership/borrowing system is hard because it creates a whole new class of side effects." I'd submit it doesn't create them... it reveals them. They've always been there. Almost every other language fails to shine the light on them, but that doesn't mean they aren't there. All GC'ed languages still have issues of ownership, especially if threaded, and all non-GC'ed languages have all the issues Rust has... it…

Don't be so quick to say that Rust is doing the "right thing" here. An early example in the article shows one of the big Rust gotchas: you want to borrow a reference to a part of a structure, but if you encapsulate that in a function which takes a reference to the enclosing structure, the entire enclosing structure is borrowed. This isn't a revealed side effect, this is an invented side effect that is an artifact of…

However, there are real lifetime and thread-safety side effects of passing a reference to the outer structure when you only need a reference to the inner structure.

In a GC'd language without an effects system, passing in a reference to the outer structure would still prevent the GC from freeing the outer structure (depending on the ABI, even if you null out the reference passed outer reference inside the function, the value passed on the stack might be immutable) and would also mean that you need to be careful about later changes causing non-thread-safe mutations to the outer structure. If your language isn't GC'd and doesn't have an effects system, then you need to manually keep track of the borrowing.

These aren't artifacts of Rust's type system; they're genuine side effects that are present but more subtle in other languages.

Re: Why Rust's ownership/borrowing is hard

#32

Post by jupp0r »

Coming from a mainly C++ background, I find that the Rust language makes best practices in languages with manual memory management (and to some degree also in garbage collected environments) explicit. This is a great property of the language and it definitely changed the my C++ programming. You can see it as automatization of the more boring aspects of code reviews.

Re: Why Rust's ownership/borrowing is hard

#33

Post by jabl »

jorgecurio wrote: post #13

Should I learn Rust in 2016? What are you guys building with it and why Rust in particular?

I'm just learning it, so I'm not (yet, at least ) doing anything awesome with it.

As for why Rust in particular, over the years I've convinced myself that software quality is one of the big ails of, well, anything which concerns itself with the creation of SW. Which is more or less anything these days in technical professions. Strong static typing, memory safety, data race freedom etc. are of course no panacea, but are at least IMHO a step in the right direction.

FWIW, I also think Haskell is totally awesome, but with my background in mostly procedural/OO languages and with small kids at home, I feel I cannot at the moment afford the time to become really productive in a pure lazy functional language in a reasonable time frame. It's on my someday TODO list, though. Oh, and I'm somewhat of a speed freak. So hence Rust.

Re: Why Rust's ownership/borrowing is hard

#34

Post by gulpahum »

dikaiosune wrote: post #3

There were also some interesting comments yesterday when this was posted to the Rust subreddit: https://www.reddit.com/r/rust/comments/45gcmh/why_rusts_owne...

There was one good point, which was also my conclusion:

"Given all that, I wonder if it makes sense to prefer plain old functions most of the time. Is that right, or am I overlooking something?"

The response was yes. Avoid impl methods which take a mutable self.

Re: Why Rust's ownership/borrowing is hard

#35

Post by rntz »

jerf wrote: post #14

"Rust's ownership/borrowing system is hard because it creates a whole new class of side effects." I'd submit it doesn't create them... it reveals them. They've always been there. Almost every other language fails to shine the light on them, but that doesn't mean they aren't there. All GC'ed languages still have issues of ownership, especially if threaded, and all non-GC'ed languages have all the issues Rust has... it…

> All GC'ed languages still have issues of ownership, especially if threaded,

This is not true. Ownership is only relevant in the presence of mutability. In a GC'ed language where most or all data is immutable, one rarely needs to think about ownership. In Rust, one needs to think about it all the time.

Rust is certainly a leg up compared to trying to write multithreaded C or C++ code, but that doesn't mean its approach is free of drawbacks.

Empirically, even in Python - a mutable-by-default language - I find myself rarely having to think about ownership. That could be an artifact of the kind of Python programs I find myself writing, though. I'd be interested to hear other people's experiences on that front.

Re: Why Rust's ownership/borrowing is hard

#36

Post by imtringued »

>Nothing in the experience of most programmers would prepare them to point suddenly stopping working after being passed to is_origin()!

I'm not even a Rust programmer and only read three paragraphs about the borrow checker and I instantly saw that point is moved.

Re: Why Rust's ownership/borrowing is hard

#37

Post by sixbrx »

rntz wrote: post #35
jerf wrote: post #14

"Rust's ownership/borrowing system is hard because it creates a whole new class of side effects." I'd submit it doesn't create them... it reveals them. They've always been there. Almost every other language fails to shine the light on them, but that doesn't mean they aren't there. All GC'ed languages still have issues of ownership, especially if threaded, and all non-GC'ed languages have all the issues Rust has... it…

> All GC'ed languages still have issues of ownership, especially if threaded, This is not true. Ownership is only relevant in the presence of mutability. In a GC'ed language where most or all data is immutable, one rarely needs to think about ownership. In Rust, one needs to think about it all the time. Rust is certainly a leg up compared to trying to write multithreaded C or C++ code, but that doesn't mean its appro…

> Ownership is only relevant in the presence of mutability. In a GC'ed language where most or all data is immutable, one rarely needs to think about ownership.

If mutability isn't needed, then you would declare the self parameter as a simple (non-exclusive) borrow, and you can borrow from it or parts of it freely without inteferance from the compiler.

Re: Why Rust's ownership/borrowing is hard

#38

Post by faboo »

jabl wrote: post #33
jorgecurio wrote: post #13

Should I learn Rust in 2016? What are you guys building with it and why Rust in particular?

I'm just learning it, so I'm not (yet, at least ) doing anything awesome with it. As for why Rust in particular, over the years I've convinced myself that software quality is one of the big ails of, well, anything which concerns itself with the creation of SW. Which is more or less anything these days in technical professions. Strong static typing, memory safety, data race freedom etc. are of course no panacea, but a…

Amusingly, I'm in the reverse situation: loving working in Haskell and reeally want to try Rust but I just don't have the time.

For what it's worth, Haskell can be compiled to code that's quite fast. Somewhat unfortunately, the difference between GHC's vanilla output and its speed-optimized output can be quite vast, which I think gives the impression that the language or a given program is necessarily slow.

Re: Why Rust's ownership/borrowing is hard

#39

Post by jeremyjh »

nostrademons wrote: post #29
klodolph wrote: post #26

Earlier quoted context omitted.

Don't be so quick to say that Rust is doing the "right thing" here. An early example in the article shows one of the big Rust gotchas: you want to borrow a reference to a part of a structure, but if you encapsulate that in a function which takes a reference to the enclosing structure, the entire enclosing structure is borrowed. This isn't a revealed side effect, this is an invented side effect that is an artifact of…

I thought that was one of the most fascinating parts - Rust's borrow-checker enforces the Law of Demeter and Principle of Least Privilege as a side-effect. Code that takes a full structure when it only needs to operate on a part of the structure is badly designed. It's not conveying the full information about the data that it actually needs, which means that unexpected dependencies can crop up, implicit in the body o…

>Code that takes a full structure when it only needs to operate on a part of the structure is badly designed.

No, it is not; this is done all the time with methods and it improves encapsulation - you may not want your clients to be able to decompose your data structures. Do you really mark every member of your data structures as pub??

Sorry but this is a poor ad-hoc defense of an actual annoyance in the borrow-checker.

Re: Why Rust's ownership/borrowing is hard

#40

Post by jerf »

klodolph wrote: post #26
jerf wrote: post #14

"Rust's ownership/borrowing system is hard because it creates a whole new class of side effects." I'd submit it doesn't create them... it reveals them. They've always been there. Almost every other language fails to shine the light on them, but that doesn't mean they aren't there. All GC'ed languages still have issues of ownership, especially if threaded, and all non-GC'ed languages have all the issues Rust has... it…

Don't be so quick to say that Rust is doing the "right thing" here. An early example in the article shows one of the big Rust gotchas: you want to borrow a reference to a part of a structure, but if you encapsulate that in a function which takes a reference to the enclosing structure, the entire enclosing structure is borrowed. This isn't a revealed side effect, this is an invented side effect that is an artifact of…

I didn't say Rust is doing the right thing. And it may create other issues where it does not 100% correctly reveal the issue.

However, I'd still say that issues arising in sharing a composite structure in pieces have always existed. Rust's solution may or may not be correct, but the issue is not something it is creating. Adopting Rust does not mean adopting a brand new set of problems that never existed before. It means seeing them clearly for what is probably the first time.

Post reply on HN