Memory safety absolutists • Hacker News Board

Re: Memory safety absolutists

#261

Post by ssokolow » Sun, Aug 02, 2026, 1:37 AM UTC

pjmlp wrote: post #190

ssokolow wrote: post #79

Earlier quoted context omitted.

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

Actually there is, given that the reference compiler depends on C++.

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

Re: Memory safety absolutists

#262

Post by ssokolow » Sun, Aug 02, 2026, 1:41 AM UTC

yjftsjthsd-h wrote: post #39

conradludgate wrote: post #32

Earlier quoted context omitted.

I don't immediately follow how Rust breaks the ecosystem. Rust has very good C FFI support and fully supports the default C ABI. It just requires unsafe bindings.

In practice, my Python packages broke when they dropped the C crypto support. I'm sure it was theoretically possible to avoid that, but they didn't. And that's ecosystem breakage. (And if the fix is that I the user must go manually install or worse compile extra things, that's definitely ecosystem breakage)

Back when that happened, this post came out: https://blog.yossarian.net/2021/02/28/Weird-architectures-we...

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.

Re: Memory safety absolutists

#263

Post by ssokolow » Sun, Aug 02, 2026, 1:45 AM UTC

tialaramex wrote: post #181

bastawhiz wrote: post #85

Earlier quoted context omitted.

That's really just not true. Easy counterexample: any codec should be written in a memory safe language. Really anything that deals with untrusted input should be memory safe. Your TLS library. A load balancer. Your password manager.

In fact codecs in particular should be written in something much stricter but more special purpose than Rust, WUFFS (Wrangling Untrusted File Formats Safely) https://github.com/google/wuffs WUFFS gives up generality - you can't write "Hello World" in WUFFS because it lacks both strings (for the "Hello, world" text) and I/O (for the printing it out). But you can write a codec, going from a block of bytes representing…

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

Re: Memory safety absolutists

#264

Post by ssokolow » Sun, Aug 02, 2026, 2:00 AM UTC

inigyou wrote: post #206

Panzerschrek wrote: post #140

Earlier quoted context omitted.

> but it's still possible to use memory incorrectly Only by misusing unsafe . Using it in regular programs actually isn't that necessary. In languages like C you have unsafe code almost in every line. > My understanding is that a memory bug is when you use memory in an unintended way Memory safety rules are more strict and formalized than you think. Memory safety issues are typically reading uninitialized memory (or…

Say I implement a dynamic array in the usual way with buffer, length, capacity. Currently the capacity is 50 and the length is 20. I access element 30 i.e. an unallocated element. Was that memory unsafe?

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

Re: Memory safety absolutists

#265

Post by ssokolow » Sun, Aug 02, 2026, 2:13 AM UTC

hitekker wrote: post #143

estebank wrote: post #9

Earlier quoted context omitted.

Could you point me at the members of the Rust project doing so? I'd want to have a word with them (I'm a member of t-compiler).

IIRC, ralfj was insinuating that Java was memory unsafe and arguing about it with experts on HN not too long ago. But I think he was coming off hot from the T-spec debacle so I understand it as him wanting to blow off steam. The most toxic Rust leaders exited from the project a few years back, though some are flaming more freely than ever, e.g., Go barely deserves to exist, “SQlite is a terrible example” etc

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.

Re: Memory safety absolutists

#266

Post by ssokolow » Sun, Aug 02, 2026, 2:15 AM UTC

inigyou wrote: post #201

userbinator wrote: post #99

Earlier quoted context omitted.

My system sometimes detects a few bitflips per day. Perhaps you should replace your RAM, or it's a sign that you have a massive source of radiation lurking somewhere?

I assumed this is just normal in DDR5 and the reason I only had motherboards with ECC to choose from. I do have quite a lot of it. It wouldn't be the first time engineers pushed something close to the unreliability limit and compensated with a mechanism to make it more reliable.

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

Re: Memory safety absolutists

#267

Post by ssokolow » Sun, Aug 02, 2026, 2:44 AM UTC

inigyou wrote: post #235

Ygg2 wrote: post #204

Earlier quoted context omitted.

Some is doing heavy misrepresentation. Latest batch of LLM's Linux had 423 vulnerabilities. Out of which 10 were Rust*. Would you prefer more or less CVEs? But it's like seat belt analogy. It's a helper not a panacea. * Granted Rust isn't in the entire kernel yet. D

That sounds like Linux has more vulnerabilities per line of Rust code than line of C code, given the language ratio...

Here's a better exploration of defect rates:

https://security.googleblog.com/2022/12/memory-safe-language...

Re: Memory safety absolutists

#268

Post by ssokolow » Sun, Aug 02, 2026, 2:45 AM UTC

userbinator wrote: post #233

benj111 wrote: post #151

Earlier quoted context omitted.

So you have a dogmatic belief, not based on evidence then.

The evidence is clear, "safety" paranoia is leading to increasing authoritarianism.

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

Re: Memory safety absolutists

#269

Post by ssokolow » Sun, Aug 02, 2026, 2:50 AM UTC

uecker wrote: post #258

Pooge wrote: post #257

Earlier quoted context omitted.

You can appreciate Rust and hate `curl | bash` at the same time. Plenty of binaries that are just download and execute.

Of course, I just wished enough Rust enthusiast cared also about other real-word security issues enough to get this fixed: https://rustup.rs/

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:

https://brew.sh/

https://nixos.org/download/

https://chocolatey.org/install#individual

https://store.steampowered.com/about/

Re: Memory safety absolutists

#270

Post by uecker » Sun, Aug 02, 2026, 5:53 PM UTC

ssokolow wrote: post #269

uecker wrote: post #258

Earlier quoted context omitted.

Of course, I just wished enough Rust enthusiast cared also about other real-word security issues enough to get this fixed: https://rustup.rs/

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 ti…

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.