> If you ... look at questions surrounding the core principles of Rust—e.g. ... ‘why does Rust’s async implementation require boxing so often?’—you’ll soon find that a lot of these restrictions are a natural consequences of the design of the language
I do find that satisfying, that "There is a reason for these restrictions" feeling.
But, I can't remember the last time I boxed an async future. Maybe because I almost never use recursion.
I'd like to see some of the author's code to see where boxing is used.
Because there’s no async fn on traits yet, almost all “async” traits are returning Pin<Box<dyn Future<Output=T>>> under the hood.
Same principle also applies if you’re trying to put a future in a struct (to create a named future). One of the fields will have more or less that type. This is useful for a few reasons (e.g. making it easy to refer to a specific future in type signatures or for writing futures out by hand).
The Rust mentality seems to be, "move fast, break things". The language features, and rustc itself, change so fast that a rustc released 3 months ago can't compile code written by someone of the Rust mentality written today.
Well this seems extremely misleading. Technically this is true: Rust doesn't have forward compatibility.
But it does have guaranteed backwards compatibility since the 1.0 in 2015, which is far more important. So "break things" really doesn't apply. It's trivial to incorporate old code last written in 2015 into brand-new projects.
And nowadays I'm not even seeing too many brand-new language features come out. GATs will land soon, but that really feels like filling out a part of the language that people would have expected to be there anyway.
I heard they use the entire 'crates' repository as test-cases for breaking changes. If that's accurate, the backwards-compatibility is commendable.
Forward-compatibility is near-impossible. Obviously it'd help if new code didn't use new features, but .. then why add them? How mature does a feature need to be before it's permitted to use them? How does a feature become mature if no-one's allowed to use it? etc.
Backwards compatibility is guaranteed afaik, the rare breaking changes are activated by setting a newer Rust "edition" in the project's config. So in theory you can just keep coding Rust 1.0 style if you remove an auto-generated line that's used to set the project to the current 2021 edition.
> How mature does a feature need to be before it's permitted to use them?
Each project has its own answer for that question; the acronym for it is MSRV (Minimum Supported Rust Version), and there's a field in the Cargo.toml for it ("rust-version"). It's not unusual to have the CI test the project with both the MSRV and the latest stable Rust version, to catch accidental use of new features. Unfortunately, there's as of yet no consensus on how to choose the MSRV. Some projects are more conservative ("the MSRV has to be at least one year old", "the MSRV is whatever comes with the oldest still supported LTS of Linux distros X and Y", "I set the MSRV once in the past and don't intend to increase it ever"), some projects are more aggressive ("we support only latest Rust and the previous one"), other projects are somewhere in the middle.
(Edit: there's at the moment a very interesting discussion about the MSRV of the "libc" crate, which a lot of other crates depend on, and MSRV in general, at https://github.com/rust-lang/libs-team/issues/72)
It isn't so much about Rust the language which would be fine if people wrote Rust code like they write, say, Bash code. Bash also gets new features that don't work in older Bash versions. But the Bash mentality means supporting all machines and not using new bash features till you can expect every machine to have it.
The Rust mentality is to use all new features immediately without consideration. And this is entirely on the Rust devs which are, naturally, for now, the bleeding edge types.
Misleading? No. This is the reality of most Rust dev behavior. But you're right in spirit, the problems aren't intrinsic to the Rust language itself.
Yes, it's more-or-less the case that you need the current Rust compiler if you want to compile a bunch of Rust projects and have no issues. But there's really no downside to this. Just grab the latest Rust version. It's free and has no breaking changes.
The only time I can see it being an issue is if you're trying to use the Debian/Ubuntu version of rustc or cargo. The version of rustc on Debian stable is 1.48, which was released in Nov 2020. I'm not sure what advantage there is to shipping such an old version of rustc when it guarantees backward compatibility, but if this is what you have then, sure, a big chunk of the Rust ecosystem won't compile.
---
I still think your original comment was misleading because you said the Rust mentality was "move fast, break things". This almost always refers to a lack of backward compatibility, when existing software no longer works with newer versions of the thing that changed.
That seems more like “move fast, add things”. I’m not sure how one could sensibly expect a compiler to be able to compile language features from the future.
I mean -- this happens, but this happens to any language, because as others have noted: forwards compatibility isn't a thing. New features will be added, and, given the track record of Rust, these new features have been pretty good!
I recently experienced this relatively trivial issue -- I had only tested some software with the latest stable Rust version, 1.62. A user reported it was not building on the Ubuntu default installed 1.59, and I decided building on that version of Ubuntu was worth it. The fix? Install and use the relevant rust toolchain `rustup default 1.59`, `cargo check` points out exactly the issue (BTW the language change was a good change!), fix and push. It was so easy.
You're getting flak for this, but you have a point.
I wouldn't say it changes very fast. If you look at the language features in the past two releases they're all of the form "allow {existing feature} to do {thing you'd expect to be allowed}", and the library additions are minor.
But it changes often, every six weeks, where e.g. Python releases features only once a year. And it's common practice to install new releases as soon as they come out without waiting for distros to pick them up. That means software starts depending on new features in minor frivolous ways that nevertheless break the build for older Rust versions.
I make an effort to have my libraries support older Rust releases, but I have to go out of my way to check for compatibility. Not everybody does that, and it's unrealistic to expect everyone to—but with a different release schedule that would give fewer issues.
> And it's common practice to install new releases as soon as they come out without waiting for distros to pick them up.
That's the problem. It's not the release schedule that's the problem. The answer I've arrived at, right now, is to make the default version of the Ubuntu LTS release immediately prior to the latest, my default.
Is that arbitrary? Yes. Might that change if some very cool Rust features are included in 1.64 -- like, if let chains? Yeah. So should the Rust community perhaps develop best practices on MSRV, at the very least notifying if a package deviates from MSRV norms? Maybe. Is this a big problem? Let's be real -- no, not really.
What you'd expect, and what I think we see, is that over time the new features are less "must have" and so fewer programmers will chase the latest version.
There's quite a gap between "Now arrays implement IntoIterator" (about a year ago, you can e.g. write for loops over an array) and "Termination is now stable" (May 2022, you can have custom exit code handling in your program)
I'm sure a few people were excited about Termination, but practically everybody uses IntoIterator and arrays. So of course they would want that feature.
As a Linux user I remember manually compiling 1.3.x back when odd numbered micro meant "Unstable" because 1.2 didn't have features I really cared about. Today I just run whatever kernel the OS installed. Are there important new Linux features in linux-next? Probably, maybe I will read about them in LWN and look forward to them, I'm definitely not going to bother compiling it by hand for any new feature I can imagine.
This also touches on a really important point -- all this takes place in a context. What is the context? One context -- sometimes there are exciting new features! Another context -- this issue is mostly about users who want to build your software from source (this isn't a problem for you, as such), but who don't want to download a new copy of the compiler to do that. Is this a large group of users, if you're not a library? I don't think so.
I have a policy that is to support at most three releases back.
Requiring upgrades to support new software is normal. New APIs are released, new features that allow for simpler code or remove unneeded unsafe blocks. These are good things.
People don’t need to install the latest software. If they want to install the latest software, then they will need to install the dependencies that support that software. That can be operating system versions, compiler versions, or other library dependencies.
I really don’t understand this mentality of wanting to update one piece of software, but also not wanting to update any other software it might depend on.
I am fairly tired of Rust devs and boosters monopolizing online spaces. There was a Zig article the other day with comments that derailed into Reasons For The Rust Way. IMHO this behavior is not helpful for PL experimentation and adoption.
I think this is fair. On the other hand, I think the flimsy arguments ("Just write better code..." and "Modern C++ doesn't have these issues..."), the mole hill matters of taste ("Egads! The syntax!" not "I think Swift does this better for the following reason..."), and the drive by hype hate, are just as tiresome from the anti-Rust crowd.
I'm admittedly a Rust booster (in the sense that I like it) and so perhaps I'm biased, but: I don't really see Rust monopolizing spaces that don't otherwise make sense?
HN has a pre-existing bias towards the newest and shiniest thing, so it's not surprising that Rust takes up a lot of the oxygen in PL conversations (especially when so many of its peers, like Zig, emphasize having fewer deviations as an advantage.) But I don't see Rust taking up a disproportionate amount of headspace in more focused technical communities.
It's not just discussions about programming languages. All kinds of HN posts about security vulnerabilities commonly get sidetracked by very predictable "if only it would be written in Rust" threads.
I guess I don't understand how that qualifies as "sidetracking." If the vulnerability in question is a spatial or temporal memory safety bug, it seems very reasonable and pertinent to observe that Rust would have prevented it.
Unless it's the volume or consistency of that reply that you're objecting to?
Yeah but does it make sense to suggest to rewrite software that are years old, have collected solutions for years and know how? Maybe rust devs could end wishing that things were written in rust and start writing things in rust
This is just completely moving the goal posts. This thread was talking about observing that a particular vulnerability would be prevented in Rust. But now you've taken it from that, to, "why not rewrite the project in Rust."
They are not the same thing.
> start writing things in rust
Yeah because nobody is writing anything in Rust. What a bunch of blowhards!
It’s when technology becomes a cult and not a tool to solve a problem, I have no interest in having a rust mentality I have an interest in having a $businessLogicSolving mentality, and some aren’t capable of understanding it, sadly
Breaking news! Some humans lose sight of the big picture!
Tune in tomorrow where we reveal that water is, to the shock of everyone, wet.
The irony is that the real big picture here is that Rust's entire purpose of being is absolutely about $businessLogicSolving. There's a real problem where software written in C or C++ for $goodReasons seems to always wind up with large numbers of security vulnerabilities caused by memory safety bugs. That's bad for business. That's basically why Rust exists.
35 comments
[ 1.7 ms ] story [ 94.5 ms ] threadI do find that satisfying, that "There is a reason for these restrictions" feeling.
But, I can't remember the last time I boxed an async future. Maybe because I almost never use recursion.
I'd like to see some of the author's code to see where boxing is used.
Same principle also applies if you’re trying to put a future in a struct (to create a named future). One of the fields will have more or less that type. This is useful for a few reasons (e.g. making it easy to refer to a specific future in type signatures or for writing futures out by hand).
But it does have guaranteed backwards compatibility since the 1.0 in 2015, which is far more important. So "break things" really doesn't apply. It's trivial to incorporate old code last written in 2015 into brand-new projects.
And nowadays I'm not even seeing too many brand-new language features come out. GATs will land soon, but that really feels like filling out a part of the language that people would have expected to be there anyway.
Forward-compatibility is near-impossible. Obviously it'd help if new code didn't use new features, but .. then why add them? How mature does a feature need to be before it's permitted to use them? How does a feature become mature if no-one's allowed to use it? etc.
Each project has its own answer for that question; the acronym for it is MSRV (Minimum Supported Rust Version), and there's a field in the Cargo.toml for it ("rust-version"). It's not unusual to have the CI test the project with both the MSRV and the latest stable Rust version, to catch accidental use of new features. Unfortunately, there's as of yet no consensus on how to choose the MSRV. Some projects are more conservative ("the MSRV has to be at least one year old", "the MSRV is whatever comes with the oldest still supported LTS of Linux distros X and Y", "I set the MSRV once in the past and don't intend to increase it ever"), some projects are more aggressive ("we support only latest Rust and the previous one"), other projects are somewhere in the middle.
(Edit: there's at the moment a very interesting discussion about the MSRV of the "libc" crate, which a lot of other crates depend on, and MSRV in general, at https://github.com/rust-lang/libs-team/issues/72)
The Rust mentality is to use all new features immediately without consideration. And this is entirely on the Rust devs which are, naturally, for now, the bleeding edge types.
Misleading? No. This is the reality of most Rust dev behavior. But you're right in spirit, the problems aren't intrinsic to the Rust language itself.
The only time I can see it being an issue is if you're trying to use the Debian/Ubuntu version of rustc or cargo. The version of rustc on Debian stable is 1.48, which was released in Nov 2020. I'm not sure what advantage there is to shipping such an old version of rustc when it guarantees backward compatibility, but if this is what you have then, sure, a big chunk of the Rust ecosystem won't compile.
---
I still think your original comment was misleading because you said the Rust mentality was "move fast, break things". This almost always refers to a lack of backward compatibility, when existing software no longer works with newer versions of the thing that changed.
I mean -- this happens, but this happens to any language, because as others have noted: forwards compatibility isn't a thing. New features will be added, and, given the track record of Rust, these new features have been pretty good!
I recently experienced this relatively trivial issue -- I had only tested some software with the latest stable Rust version, 1.62. A user reported it was not building on the Ubuntu default installed 1.59, and I decided building on that version of Ubuntu was worth it. The fix? Install and use the relevant rust toolchain `rustup default 1.59`, `cargo check` points out exactly the issue (BTW the language change was a good change!), fix and push. It was so easy.
I wouldn't say it changes very fast. If you look at the language features in the past two releases they're all of the form "allow {existing feature} to do {thing you'd expect to be allowed}", and the library additions are minor.
But it changes often, every six weeks, where e.g. Python releases features only once a year. And it's common practice to install new releases as soon as they come out without waiting for distros to pick them up. That means software starts depending on new features in minor frivolous ways that nevertheless break the build for older Rust versions.
I make an effort to have my libraries support older Rust releases, but I have to go out of my way to check for compatibility. Not everybody does that, and it's unrealistic to expect everyone to—but with a different release schedule that would give fewer issues.
That's the problem. It's not the release schedule that's the problem. The answer I've arrived at, right now, is to make the default version of the Ubuntu LTS release immediately prior to the latest, my default.
Is that arbitrary? Yes. Might that change if some very cool Rust features are included in 1.64 -- like, if let chains? Yeah. So should the Rust community perhaps develop best practices on MSRV, at the very least notifying if a package deviates from MSRV norms? Maybe. Is this a big problem? Let's be real -- no, not really.
There's quite a gap between "Now arrays implement IntoIterator" (about a year ago, you can e.g. write for loops over an array) and "Termination is now stable" (May 2022, you can have custom exit code handling in your program)
I'm sure a few people were excited about Termination, but practically everybody uses IntoIterator and arrays. So of course they would want that feature.
As a Linux user I remember manually compiling 1.3.x back when odd numbered micro meant "Unstable" because 1.2 didn't have features I really cared about. Today I just run whatever kernel the OS installed. Are there important new Linux features in linux-next? Probably, maybe I will read about them in LWN and look forward to them, I'm definitely not going to bother compiling it by hand for any new feature I can imagine.
Requiring upgrades to support new software is normal. New APIs are released, new features that allow for simpler code or remove unneeded unsafe blocks. These are good things.
People don’t need to install the latest software. If they want to install the latest software, then they will need to install the dependencies that support that software. That can be operating system versions, compiler versions, or other library dependencies.
I really don’t understand this mentality of wanting to update one piece of software, but also not wanting to update any other software it might depend on.
HN has a pre-existing bias towards the newest and shiniest thing, so it's not surprising that Rust takes up a lot of the oxygen in PL conversations (especially when so many of its peers, like Zig, emphasize having fewer deviations as an advantage.) But I don't see Rust taking up a disproportionate amount of headspace in more focused technical communities.
Unless it's the volume or consistency of that reply that you're objecting to?
They are, though. Like, I don't even disagree with the cost of rewriting, but there are very much active efforts to rewrite things in rust (ex. coreutils - https://github.com/uutils/coreutils , OS - https://www.redox-os.org/ ) or to add rust to existing projects (Linux, Firefox and Chrome both (https://chromium.googlesource.com/chromium/src/+/refs/heads/...)).
They are not the same thing.
> start writing things in rust
Yeah because nobody is writing anything in Rust. What a bunch of blowhards!
Tune in tomorrow where we reveal that water is, to the shock of everyone, wet.
The irony is that the real big picture here is that Rust's entire purpose of being is absolutely about $businessLogicSolving. There's a real problem where software written in C or C++ for $goodReasons seems to always wind up with large numbers of security vulnerabilities caused by memory safety bugs. That's bad for business. That's basically why Rust exists.
Because content wise there was almost nothing in this article.