Building a Rust Mentality
slightknack.dev
slightknack.dev
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.
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).
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.
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.