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

Visualize Ownership and Lifetimes in Rust

github.com

Post reply on HN
Print view View original

31–40 of 64 posts

Re: Visualize Ownership and Lifetimes in Rust

#31

Post by cageface »

diggan wrote: post #30
cageface wrote: post #20

Earlier quoted context omitted.

I recently came to this realization in a large typescript codebase. It's really important to understand who owns data and who has the right to modify it. Having tools to manage this and make it explicit built into the language is so helpful for code correctness and is especially beneficial for maintaining code you didn't write yourself.

Another great way of handling this if you cannot switch out the language, is to start adopting a more functional approach and also try to keep mutations into one place/less places. So instead of having all the X services/adapter/whatever being able to pass data around that they mutate along the way (like the typical "hiding implementation details in objects/classes"), have all those just do transformation on data and…

Right this is what I tried to do but unfortunately trying to mark everything immutable in Typescript leads to some very unergonomic type signatures. Hopefully this can improve in the future.

Re: Visualize Ownership and Lifetimes in Rust

#32

Post by diggan »

cageface wrote: post #31
diggan wrote: post #30

Earlier quoted context omitted.

Another great way of handling this if you cannot switch out the language, is to start adopting a more functional approach and also try to keep mutations into one place/less places. So instead of having all the X services/adapter/whatever being able to pass data around that they mutate along the way (like the typical "hiding implementation details in objects/classes"), have all those just do transformation on data and…

Right this is what I tried to do but unfortunately trying to mark everything immutable in Typescript leads to some very unergonomic type signatures. Hopefully this can improve in the future.

Could you show an example of what you mean? Not sure how not mutating data would lead to more unergonomic type signatures, I'm sure an example would help me understand. Although it wouldn't surprise me TypeScript makes things harder.

Re: Visualize Ownership and Lifetimes in Rust

#33

Post by NoboruWataya »

mrbonner wrote: post #2

How many of those advanced concept in Rust such as borrow checker & lifetime could be avoided as a beginner? If utmost performance is not required (i.e., for mortals dealing with Java/Python/JS on a daily basis) would those lifetime and borrow checker concepts be a hinder to move quick? I read this article https://corrode.dev/blog/prototyping/ and it seems to address almost all of my concerns when I started learning…

I think you will run into the borrow checker pretty soon, because you have to deal with it whenever you deal with references (which you will inevitably have to do if you are dealing with anything more complex than number types). But that aspect of the borrow checker is not that difficult. You could avoid it entirely by cloning everything but IMO it's not necessary and you would do better to invest a small amount of time in understanding why the borrow checker is complaining.

Lifetimes you can probably get further without having to deal with. Just avoid storing references in structs and you will avoid a lot of lifetime headaches. Cloning can again be helpful here.

An alternative to cloning everything, if you are dealing with simple data types, is to derive copy for your structs so you can pass them around without worrying about ownership. It's not always possible though.

Smart pointers are another workaround, as others have said. But my problem with (some) smart pointers is that they simply move the checks to runtime, meaning now your code has a much higher chance of panicking at runtime.

Re: Visualize Ownership and Lifetimes in Rust

#34

Post by tialaramex »

nicce wrote: post #24
juped wrote: post #23

Earlier quoted context omitted.

Rustrover can do this, although unfortunately it requires cargo check/clippy turned on rather than being native (still faster than LSP, at least). https://www.jetbrains.com/help/rust/rust-external-linters.ht...

I have found clippy better anyway.

Clippy lints are nice. I'm a particular fan of `while_let_loop` which is basically Clippy looks at a Rust loop you wrote and it says "Hey, this is equivalent to while let SomePatternHere = some_function(blah) { };" and mostly you realise oh yes it is, and that's much clearer than what I wrote.

Once in a while I get that lint and I think no, what I wrote is easier to understand, and I just #[allow(clippy::while_let_loop)] to acknowledge that.

The way I end up with these loops is I realise I need a loop - we're definitely doing something here more than once, so in Rust that's loop - then during further development and refinement of the software I get the exact rules correct and then it's obvious (to clippy) that this is a while-let loop, often it's in the form while let Some(thing) = container.pop() { /* do stuff with the thing, maybe putting more stuff in the container in the process */ }; but the loop { } construction is harder to read if left in that form and the whole point of source code is to be readable to humans.

Many languages don't like to give these diagnostics names. The reality is that these names mean something. If you called it 81402 then now that's just arcane knowledge, like if you insisted on calling all the elements by their atomic number. If we call it "Element 26" rather than "Iron" it's the same except harder to remember. I think software which uses numbers here is trying to avoid the semantic value, but that's never going to work, so just embrace it.

Re: Visualize Ownership and Lifetimes in Rust

#35

Post by Xunjin »

sundarurfriend wrote: post #11
Xunjin wrote: post #10

Earlier quoted context omitted.

I actually thought was the Phoronix user called Volta who wrote that comment.

Phoronix seems to be some Linux benchmarking software that also has a "Linux content" website? I didn't know it had a (in?)famous comment section nor recurring personalities and feuds from it. The Internet today really is bubbles inside bubbles inside bubbles.

It does have a forum which has great people with constructive discussions, but at the same time there are few users who level up the toxicity that even Michael Larabel can't manage it at all.

For example, the discussion/topic of the Nouveau dev who left the Linux had to be closed.

Re: Visualize Ownership and Lifetimes in Rust

#37

Post by gpm »

superkuh wrote: post #36

It's too bad the lifetime of rustc is only about 3 months before breaking changes (new features, updates, etc) are introduced to the compiler and used by devs.

New features aren't usually considered breaking changes, only modifying existing ones so that old code doesn't work.

The rust compiler never strives to never introduce breaking changes (by the definition I just described). It doesn't quite succeed (because some things like correctness are considered more important), but it fails

a) Very rarely, not once every 3 months.

b) In very small ways, that only break a tiny portion of code.

c) In ways that are very easy to fix.

d) Usually the rustc-devs will go offer patches to the entire open source ecosystem before any such release.

Re: Visualize Ownership and Lifetimes in Rust

#38

Post by tekkk »

diggan wrote: post #32
cageface wrote: post #31

Earlier quoted context omitted.

Right this is what I tried to do but unfortunately trying to mark everything immutable in Typescript leads to some very unergonomic type signatures. Hopefully this can improve in the future.

Could you show an example of what you mean? Not sure how not mutating data would lead to more unergonomic type signatures, I'm sure an example would help me understand. Although it wouldn't surprise me TypeScript makes things harder.

You are polluting every variable signature with `readonly`. This also can create cascading effects where making one function accept only readonly variables forces you to declare readonly elsewhere as well. Quite similar, in a way, to Rust.

Re: Visualize Ownership and Lifetimes in Rust

#39

Post by superkuh »

gpm wrote: post #37
superkuh wrote: post #36

It's too bad the lifetime of rustc is only about 3 months before breaking changes (new features, updates, etc) are introduced to the compiler and used by devs.

New features aren't usually considered breaking changes, only modifying existing ones so that old code doesn't work. The rust compiler never strives to never introduce breaking changes (by the definition I just described). It doesn't quite succeed (because some things like correctness are considered more important), but it fails a) Very rarely, not once every 3 months. b) In very small ways, that only break a tiny po…

I imagine that is a dev's perception (in shipping rust binaries to users) with their rolling OS and constantly updated rustc. But as a user trying to compile rust code written by rust devs what happens is that it won't compile because the compiler is 3 months out of date and rust devs immediately use new features. I had this happen personally often enough it put me off even trying out rust written applications. This is not things I've heard. It is things I've directly experienced.

rustc is a rolling only compiler and that's not great and it does break often (not be able to compile code) in distros that are not rolling. And no, curl|sh and/or rustup are not solutions. I think the only solution is waiting for rust to become popular enough that the proportion of bleeding edge using devs to normal devs goes down.

Re: Visualize Ownership and Lifetimes in Rust

#40

Post by [deleted] »

juped wrote: post #22
mrbonner wrote: post #2

How many of those advanced concept in Rust such as borrow checker & lifetime could be avoided as a beginner? If utmost performance is not required (i.e., for mortals dealing with Java/Python/JS on a daily basis) would those lifetime and borrow checker concepts be a hinder to move quick? I read this article https://corrode.dev/blog/prototyping/ and it seems to address almost all of my concerns when I started learning…

None. And lifetime elision and other forms of pretending to beginners that they don't exist are why so many people have trouble with Rust.

[deleted]
Post reply on HN