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

51–60 of 64 posts

Re: Visualize Ownership and Lifetimes in Rust

#51

Post by wavemode »

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…

No, Rust definitely does add some additional complexity on top of the inherent complexity of ownership. Despite what some people think, Rust's borrowing rules are actually extremely simple. So simple that they reject a lot of safe programs.

Paradoxically, programmer life would be made simpler if there were some more complex borrowing rules, that would allow (for example) partial borrows of objects, or allow aliasing &mut in single-threaded circumstances where it's known to be safe (i.e. when the data is something primitive like an int, where it doesn't actually matter if it's overwritten while referenced).

But I know there's extra language design complexity that this introduces, and extra codegen complexity (Rust makes certain aliasing promises to LLVM that it isn't allowed to break) so it will take time. But, there are proposals in the works.

Re: Visualize Ownership and Lifetimes in Rust

#52

Post by gpm »

wavemode wrote: post #51
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…

No, Rust definitely does add some additional complexity on top of the inherent complexity of ownership. Despite what some people think, Rust's borrowing rules are actually extremely simple. So simple that they reject a lot of safe programs. Paradoxically, programmer life would be made simpler if there were some more complex borrowing rules, that would allow (for example) partial borrows of objects, or allow aliasing…

> or allow aliasing &mut in single-threaded circumstances where it's known to be safe (i.e. when the data is something primitive like an int, where it doesn't actually matter if it's overwritten while referenced).

Incidentally this is basically what the `Cell` type does. I suspect that making it the default wouldn't make it harder for me to reason about the code I'm working on - but it is an interesting proposal.

Re: Visualize Ownership and Lifetimes in Rust

#53

Post by juped »

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.

It's slow to call out to external linters. But it's even slower to use LSP (which rustrover saves me from), it's really not a huge deal in practice for me.

Re: Visualize Ownership and Lifetimes in Rust

#54

Post by duped »

superkuh wrote: post #50
duped wrote: post #49

Earlier quoted context omitted.

> And no, curl|sh and/or rustup are not solutions. I'm confused - you are frustrated that the official release channel of software that is used by almost all users of that software is "not a solution" because you want to use unofficial release channels that have outdated versions of the software that are much more rarely used?

Correct. I avoid rust because it is a language where it's pretty much infeasible to have a compiler from your system repositories unless it's a rolling distro. Having some random application require updates so often (like a browser) is marginally acceptable if distasteful. But a compiler and toolchain that exists entirely outside my distro? No thanks. What I am confused about is how everyone is pretending this is a n…

It's totally normal except for C/C++ toolchains on Linux. C/C++ compilers are managed this way on MacOS, Windows, and by most embedded toolchains.

Why don't you want your toolchain managed outside your distro? Don't you want your software to run outside your distro?

Re: Visualize Ownership and Lifetimes in Rust

#55

Post by nocarrier »

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…

That article on rapid Rust prototyping matches my experience with using Rust as the backend for a web and iOS app. I used clone() and Vec and String and other shortcuts from that article as much as possible since I was building a backend application versus an operating system. It enabled a lot more velocity and made it fun to add features. And it was still blazing fast.

If anyone is considering using Rust and is nervous about lifetimes and bare metal, check out that article and try its guidance. I learned these things on my own the hard way and would have loved to read this article 18 months ago. It's really quite good.

Re: Visualize Ownership and Lifetimes in Rust

#56

Post by the_gipsy »

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…

You can skip lifetimes in the beginning, and I think that's the sane thing to do, if you come from a GC languages.

Borrow checker, well, this actually includes lifetimes. But let's say "basic ownership and basic borrowing", there is no way around starting with that, and it should be a point to learning rust.

Re: Visualize Ownership and Lifetimes in Rust

#57

Post by eaglelamp »

gpm wrote: post #18
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…

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…

Couldn't the same guarantees be achieved with immutability? Of course this would be setting aside concerns with performance/resource usage, but the parent is describing an environment where these concerns are not primary.

Personally I find it much easier to grok immutable data, not just understand when concentrating on it, then ownership rules.

Re: Visualize Ownership and Lifetimes in Rust

#58

Post by gpm »

eaglelamp wrote: post #57
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…

Couldn't the same guarantees be achieved with immutability? Of course this would be setting aside concerns with performance/resource usage, but the parent is describing an environment where these concerns are not primary. Personally I find it much easier to grok immutable data, not just understand when concentrating on it, then ownership rules.

Absolutely, with full immutability the borrow checker doesn't give you much at all.

It also doesn't cost you much, the borrow checker just gets out of your way if you just wrap all your immutable data in reference counted pointers (try out imbl [1] for instance). It's not free - there's some syntax overhead compared to a language that was intended to primarily work this way - but it's cheap.

I think it's reasonable to view the borrow checker as a generalization of immutability. Immutability says "no mutation", the borrow checker says "no mutation unless you are the only thing that might be accessing the data". Edit: Worth noting though that the rust standard library and ecosystem is a take on this that doesn't emphasize staying within the fully immutable regime as much as it could, instead preferring to improve performance. A variant of rust that tried to explore keeping more things immutable would be interesting.

Personally my take is that there are some problems which are very naturally represented immutably, and there are others that are very hard to fit in that framework. The borrow checker is general enough to capture almost all of that second category as well. But if you're firmly in the first category, and you aren't worried about every last drop of performance, there's probably some managed language with strong immutability that is a better fit.

[1] https://github.com/jneem/imbl

Re: Visualize Ownership and Lifetimes in Rust

#59

Post by selfmodruntime »

wavemode wrote: post #51
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…

No, Rust definitely does add some additional complexity on top of the inherent complexity of ownership. Despite what some people think, Rust's borrowing rules are actually extremely simple. So simple that they reject a lot of safe programs. Paradoxically, programmer life would be made simpler if there were some more complex borrowing rules, that would allow (for example) partial borrows of objects, or allow aliasing…

Partial borrowing is not that much of a problem for the borrow checker. It is a problem for bikeshedding core language developers, apparently...

Re: Visualize Ownership and Lifetimes in Rust

#60

Post by actionfromafar »

duped wrote: post #54
superkuh wrote: post #50

Earlier quoted context omitted.

Correct. I avoid rust because it is a language where it's pretty much infeasible to have a compiler from your system repositories unless it's a rolling distro. Having some random application require updates so often (like a browser) is marginally acceptable if distasteful. But a compiler and toolchain that exists entirely outside my distro? No thanks. What I am confused about is how everyone is pretending this is a n…

It's totally normal except for C/C++ toolchains on Linux . C/C++ compilers are managed this way on MacOS, Windows, and by most embedded toolchains. Why don't you want your toolchain managed outside your distro? Don't you want your software to run outside your distro?

Longing for a more stable world doesn't sound very weird to me. Maybe core Rust development will slow down in the future.
Post reply on HN