ssokolow

By that simplistic logic, we should ban all seatbelts and airbags because they cause authoritarianism.

*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.

That's not a property of the language, it's just an optimization they made in line with the "Release a minimum viable product, then improve it" strategy they inherited from Mozilla.

Just look at how long it took LLVM to catch up to GCC. Writing a competitive optimizer pipeline is hard work.

"No room for a language above assembly and below Rust" is a design goal for what it's reasonable to build with it.

If anything, using LLVM for the default backend is completely on-brand with how much priority Rust puts on being suitable for partially or incrementally rewriting C codebases.

(Sorry for the slow reply. The tab got buried.)

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.

Bearing in mind that "there should be no room for a language above assembly and below Rust" (i.e. something like what C or C++ is to Python, Java, C#, etc.) was an intentional design decision for Rust which resulted in `unsafe`.

True... but if you go by what you're most likely to encounter, I'd argue the biggest unaddressed flaw in Rust is the lack of a current, maintained analogue to tools like Rustig! and findpanics, which would analyze your compiled, optimized binary and report any code paths which lead to panics.

I don't like having to contort my code to fit each unit of work into the API of `std::panic::catch_unwind` so I can responsibily distrust the transitive dependencies beyond the reach of my Clippy lints.

*nod* They're from before I started bookmarking rigorously, but in the early days of Rust, there was a sentiment in the blog posts from the people developing it that the point of Rust was "to give good ideas a second chance" and that Rust was intentionally boring and un-innovative.