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

41–50 of 64 posts

Re: Visualize Ownership and Lifetimes in Rust

#41

Post by gpm »

superkuh wrote: post #39
gpm wrote: post #37

Earlier quoted context omitted.

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…

Right, that's usually described as "forwards compatibility", and yes, rust the language doesn't attempt to supply it. And yes, rustup is in fact a (the) solution for users. Distros increasingly package it because it is the recommended way to use the rust compiler (e.g. if you're on the latest ubuntu or any of its derivatives you can install it with apt instead of curl|sh).

A decent portion of projects, especially bigger ones, will try to support stables going back a few versions, but at best they're just changing the timeline slightly. This is really intended to help packaging for distributions, not users. Users should just use a compiler at least as up-to-date as the software they are trying to build.

Re: Visualize Ownership and Lifetimes in Rust

#43

Post by superkuh »

gpm wrote: post #41
superkuh wrote: post #39

Earlier quoted context omitted.

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…

Right, that's usually described as "forwards compatibility", and yes, rust the language doesn't attempt to supply it. And yes, rustup is in fact a (the) solution for users. Distros increasingly package it because it is the recommended way to use the rust compiler (e.g. if you're on the latest ubuntu or any of its derivatives you can install it with apt instead of curl|sh). A decent portion of projects, especially big…

Exactly. rustc has a lifetime of about 3 months. gcc has a lifetime of about 5-10 years. Perl's interpreter has a lifetime of about 20 years.

edit since I can't reply: The difference is that Perl devs don't immediately use the new features (and Perl 6 is not Perl). Bash too constantly gets incompatible (forwards) changes, but no Bash dev is so inconsiderate as to use these as they want their software to actually run on people's machines.

That's my entire point: rust's immature/bleeding edge dev culture causes the problem. rustc could be okay, but the culture is too bleeding edge for using rust software now. Maybe in a decade it'll settle down.

Re: Visualize Ownership and Lifetimes in Rust

#44

Post by cageface »

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.

If I have a complex structure MyStruct that I make recursively readonly it doesn't show up in the IDE as DeepReadOnly or something like that. It shows up as a huge tree of nested readonly declarations, so the original type is highly obscured.

Re: Visualize Ownership and Lifetimes in Rust

#45

Post by mrbonner »

NoboruWataya wrote: post #33
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 t…

That's basically being the point of the article I shared

Re: Visualize Ownership and Lifetimes in Rust

#46

Post by gpm »

superkuh wrote: post #43
gpm wrote: post #41

Earlier quoted context omitted.

Right, that's usually described as "forwards compatibility", and yes, rust the language doesn't attempt to supply it. And yes, rustup is in fact a (the) solution for users. Distros increasingly package it because it is the recommended way to use the rust compiler (e.g. if you're on the latest ubuntu or any of its derivatives you can install it with apt instead of curl|sh). A decent portion of projects, especially big…

Exactly. rustc has a lifetime of about 3 months. gcc has a lifetime of about 5-10 years. Perl's interpreter has a lifetime of about 20 years. edit since I can't reply : The difference is that Perl devs don't immediately use the new features (and Perl 6 is not Perl). Bash too constantly gets incompatible (forwards) changes, but no Bash dev is so inconsiderate as to use these as they want their software to actually run…

Perl 5 introduced forwards incompatible changes less than a year ago. Perl 6 was so backwards incompatible that after 20 years of work they renamed the language to something else - it last had forwards incompatible changes sometime in january.

Not only are these not meaningfully better, they're also the opposite of what I would hold out as a "successful versioning model".

Rustc lasts until you are using software that depends on a more modern version of rustc, just like any dependency. Then you upgrade it - which just like any dependency with backwards compatibility - is painless (and in fact entirely transparent if you use tooling like rustup).

Re: Visualize Ownership and Lifetimes in Rust

#48

Post by csomar »

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 Arc> your way out of ownership/borrowing. At some point, you'll start to see your program as just data (and functional programming will make sense as the only way to program) moving around. I think it's an under-rated way to get started (I started that way) and at some point a bulb will light up and you'll start seeing programming as data moving around and you'll care about ownership/borrowing at the foundational/prototype level.

Re: Visualize Ownership and Lifetimes in Rust

#49

Post by duped »

superkuh wrote: post #39
gpm wrote: post #37

Earlier quoted context omitted.

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…

> 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?

Re: Visualize Ownership and Lifetimes in Rust

#50

Post by superkuh »

duped wrote: post #49
superkuh wrote: post #39

Earlier quoted context omitted.

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…

> 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 normal software situation. It's vastly weird and different from most compilers and toolchains. It may be normal if you're coming from web dev but web dev is not normal and not a healthy ecosystem.

Post reply on HN