If you're offering a new package manager up for installation (which, Steam aside, isn't the kind of thing that's normally practical to put inside a Flatpak sandbox) on a platform where every distro has its own package manager and repository, what would you propose?
There's a reason they offer "download and run this .exe" on Windows and "download and run this .sh" on POSIX platforms.
...plus, as they mention in the tiny "other installation methods" link, none of the distro packages are official and people have a nasty habit of coming to you for support even if you didn't point them at the downstream-patched distro package they found.
Given how much distro packagers have tried to contort Rust to fit into their pre-existing `.so`-centric packaging system, I can see why Rust upstream would want to downplay that option to avoid headaches.
Let's compare what some other supplementary package managers tell people to do:
Sorry, that others are equally bad is not an excuse, and also not that Rust's design makes it more difficult to package. Either you care about security or you don't.
My point is that your argument is comparable to faulting Ford for making cars disposable with crumple zones when nobody else has found a better way to meet the crash-safety requirements while satisfying the other requirements too.
TL;DR: It's not a Rust thing. C++ suffers from the same problem when you use templates in your APIs... it just emits a .so file with no contents if you expose only templated APIs. It's fundamentally a problem of "Unless you're willing to spend Swift-level engineering money and still accept compromises Rust and C++ can't afford, dynamic linking in the presence of monomorphic generics is a problem even research languages haven't solved".
...same as the warts in async Rust. What you're seeing is a cutting-edge language slamming up against the limitations of what cutting-edge programming language research has figured out.
At least, with Rust, you've still got the dependency tracking and automatic RUSTSEC advisory tooling you don't get with header-only C libraries.
*nod* I remember an interview with Steve Gibson (author of SpinRite) 10 or 20 years ago where he was talking about how much modern-at-the-time hard drives relied on ECC to reliably achieve higher data densities when it used to be a sign of a drive going bad.
I remember seeing a blog post about that years ago and I probably bookmarked it but Firefox doesn't seem to have a way to search bookmarks for "Java" but not "JavaScript" and it appears "memory" wasn't part of the page title.
(And it's entirely possible it was back when I ONLY saved a copy of articles of that tier of "I may need this again" via ScrapBook/WebScrapBook, I haven't yet set up the browser/indexer for those and a few quick ripgrep searches aren't turning it up.)
I believe it had something to do with the JVM having some flawed semantics which couldn't be fixed without breaking compatibility with existing bytecode.
Yes. In practical terms, because optimizers like GCC and LLVM track uninitialized values and it's undefined behaviour to read from them, so you essentially have a split between what memory is allocated from the perspective of write operations (capacity) and what memory is allocated from the perspective of read operations (length).
On an academic level, memory safety is split into "spatial" and "temporal" cases and one that Wikipedia calls "spatiotemporal", with reading off the end of "capacity" being a spatial memory safety bug and reading within "capacity" before initializing being a temporal memory safety bug.
The other temporal memory safety types as Wikipedia enumerates them are:
* Use after free
* Double free
* Mismatched free (stuff like not using the free() from the same DLL that called malloc(), mixing up malloc/free with new/delete, etc.)
*nod* As someone who came from Python for easier maintainership (strong compile-time checks, an ecosystem that tries to follow the toolchain's "fearless upgrades" philosophy, almost Go-like ease of deployment, etc.) I'd LOVE if someone made a Rust implementation of WUFFS so I didn't have to choose between stronger compile-time checks and less painful build automation and cross-compilation.
TL;DR: Look at it from our perspective. It's not reasonable for us to be beholden to the limitations of build targets we never consented to supporting and possibly didn't even know about.
The word "correct" already had a meaning. Memory safety is a subset of correctness in the same way that Rust can't statically prevent race conditions but it can prevent a subset of them called data races.
There's a reason they offer "download and run this .exe" on Windows and "download and run this .sh" on POSIX platforms.
...plus, as they mention in the tiny "other installation methods" link, none of the distro packages are official and people have a nasty habit of coming to you for support even if you didn't point them at the downstream-patched distro package they found.
Given how much distro packagers have tried to contort Rust to fit into their pre-existing `.so`-centric packaging system, I can see why Rust upstream would want to downplay that option to avoid headaches.
Let's compare what some other supplementary package managers tell people to do:
https://brew.sh/
https://nixos.org/download/
https://chocolatey.org/install#individual
https://store.steampowered.com/about/