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

21–30 of 64 posts

Re: Visualize Ownership and Lifetimes in Rust

#21

Post by baq »

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…

Ownership isn’t an advanced concept. It is a software engineering problem, not a rust problem. Rust is one of the few languages which make it explicit and even checkable at compile time and the first popular one.

What is hard is designing systems in a way resource ownership can be tracked and controlled without impacting performance. Rust makes it possible, but you can use smart pointers to give up speed and take simplicity instead. Most other languages assume (rightly so) you’re too dumb to do it correctly and give you smart pointers by default; some assume you’re smart enough and are proven wrong all the time (this is assembly and C relatives; actually they say ‘we don’t want smart pointers and we want a simple compiler, sucks to be you’).

Re: Visualize Ownership and Lifetimes in Rust

#22

Post by juped »

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.

Re: Visualize Ownership and Lifetimes in Rust

#24

Post by nicce »

juped wrote: post #23
ninetyninenine wrote: post #3

Id like a plugin for rustrover.

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.

Re: Visualize Ownership and Lifetimes in Rust

#25

Post by ForHackernews »

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…

... just write Java/Python/JS, then? Or Kotlin, Typescript, Python+type annotations if you're feeling more modern.

There's nothing wrong with any of those languages (mostly) and not everything has to be written in Rust. IMHO the real value of Rust is as a systems programming language that's safer than C.

Re: Visualize Ownership and Lifetimes in Rust

#26

Post by lenkite »

baq wrote: post #21
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…

Ownership isn’t an advanced concept. It is a software engineering problem, not a rust problem. Rust is one of the few languages which make it explicit and even checkable at compile time and the first popular one. What is hard is designing systems in a way resource ownership can be tracked and controlled without impacting performance. Rust makes it possible, but you can use smart pointers to give up speed and take sim…

It very quickly becomes a special Rust-only software engineering problem. Rust has no partial borrows and this affects many designs where a lot of data needs to access fields of other data. Consequently, you see humongous large, flat structures in many Rust projects. And of-course, the famous "replace references with array indices" and just skip the borrow checking and lifetime rules by simply making your own custom pointer system - which is also common in many Rust projects and famously popularized by the "Object Soup is Made of Indices" Rust post here on HN.

Re: Visualize Ownership and Lifetimes in Rust

#27

Post by baq »

lenkite wrote: post #26
baq wrote: post #21

Earlier quoted context omitted.

Ownership isn’t an advanced concept. It is a software engineering problem, not a rust problem. Rust is one of the few languages which make it explicit and even checkable at compile time and the first popular one. What is hard is designing systems in a way resource ownership can be tracked and controlled without impacting performance. Rust makes it possible, but you can use smart pointers to give up speed and take sim…

It very quickly becomes a special Rust-only software engineering problem. Rust has no partial borrows and this affects many designs where a lot of data needs to access fields of other data. Consequently, you see humongous large, flat structures in many Rust projects. And of-course, the famous "replace references with array indices" and just skip the borrow checking and lifetime rules by simply making your own custom…

I assume you mean these are bad things; I see it as 'ownership enforcement pushing architecture towards memory safety' thing. Path of least resistance changes for the better - if you don't want to use a Box or a RefCell, that is.

Re: Visualize Ownership and Lifetimes in Rust

#28

Post by lenkite »

baq wrote: post #27
lenkite wrote: post #26

Earlier quoted context omitted.

It very quickly becomes a special Rust-only software engineering problem. Rust has no partial borrows and this affects many designs where a lot of data needs to access fields of other data. Consequently, you see humongous large, flat structures in many Rust projects. And of-course, the famous "replace references with array indices" and just skip the borrow checking and lifetime rules by simply making your own custom…

I assume you mean these are bad things; I see it as 'ownership enforcement pushing architecture towards memory safety' thing. Path of least resistance changes for the better - if you don't want to use a Box or a RefCell, that is.

Yes, these are bad things. The extreme burden imposed by lifetimes and the prevention of easy refactoring for changes causes spectacular design bloat via workarounds and safety circumvention mechanisms which are unique to Rust projects. Its a special and necessary Rust skill.

Re: Visualize Ownership and Lifetimes in Rust

#29

Post by baq »

lenkite wrote: post #28
baq wrote: post #27

Earlier quoted context omitted.

I assume you mean these are bad things; I see it as 'ownership enforcement pushing architecture towards memory safety' thing. Path of least resistance changes for the better - if you don't want to use a Box or a RefCell, that is.

Yes, these are bad things. The extreme burden imposed by lifetimes and the prevention of easy refactoring for changes causes spectacular design bloat via workarounds and safety circumvention mechanisms which are unique to Rust projects. Its a special and necessary Rust skill.

You only need to circumvent safety if you have it...

You can choose to have it in runtime. You don't get that choice pretty much anywhere else. If you don't want to make that choice in a granular way as rust allows, pick a language from the other two groups.

Re: Visualize Ownership and Lifetimes in Rust

#30

Post by diggan »

cageface wrote: post #20
gpm wrote: post #18

Earlier quoted context omitted.

The borrow checker and lifetimes aren't simply a matter of performance, they are a matter of correctness. Languages without them (go, java, etc) allow for bugs that they prevent - dataraces, ConcurrentModificationException, etc. The fact that you can only write through pointers that guarantee they have unique access is what lets the language statically guarantee the absence of a wide category of bugs, and what makes…

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 return new data, then have one thing that can mutate things.

Even if you cannot go as extreme as isolating the mutation into just one place, heavily reducing the amount of mutation makes that particular problem a lot easier to handle in larger codebases.

Post reply on HN