Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Memory safety absolutists

itsallaboutthebit.com

Post reply on HN
Print view View original

21–30 of 272 posts

Re: Memory safety absolutists

#21

Post by smj-edison »

This is perhaps a different take, but one reason I love Zig and C is because I've learned how to reason in pointers. I've worked with Rust in the past on a ~12,000 LOC side project, so I was all in with tree ownership and XOR mutability. But it turns out there's all sorts of delightful data structures that you can only express with unsafe in Rust. Intrusive doubly linked lists are the coolest thing ever. The fact that I can have a LRU cache that changes what's at the front by shuffling some pointers, while still keeping stable addresses so the hash map stays stable? That's freaking cool. Atomic operations with pointers for linked lists is really slick for implementing an allocator's free list between threads. Being able to walk a live heap using a breadth first search by just... following pointers, made the elegance of Dijkstra's algorithm come alive.

Now, maybe I'm only running into these algorithms because these are the problems I'm running into, but in the Rust community I consistently got the message that linked lists were a legacy data structure. In some cases they are, but when they do apply they do so brilliantly.

I know working in Zig leaves plenty of room for memory unsafety. Perhaps that's a bad thing. But I'm implementing an interpreter, and these algorithms are essential for it to run fast. I really do need to be aware of where every allocation happens, and what instructions the computer is running. So for now I stick with Zig, even though I know I'm opening myself up to memory exploits.

Re: Memory safety absolutists

#22

Post by yjftsjthsd-h »

> But Rust is unsafe, isn't it? It has unsafe after all! If you want to be that strict, or in other words, if you are a memory safety absolutist, that may well be true for you. I, and I hope most people, am more pragmatic than that.

So... Yes, Rust is less safe. Just that now the Rust apologist wants to back away from that and say that actually memory safety isn't actually the end all be all. C has a lot of security problems. Rust has less, at the cost of breaking the ecosystem. Fil-C has even less, and breaks the ecosystem. Why is the place Rust stops now suddenly good enough?

Re: Memory safety absolutists

#23

Post by consumer451 »

himata4113 wrote: post #2

My biggest problem with the refusal to be memory safe is the fact that those problems end up becoming my problems when I am forced to use these applications and I have to think about how there might be a zero-click zero-day that uses an overflow in some random codec. Not as a software developer, but a regular person I want my application to be written in rust or at least use fil-c at bare minimum. Now as a software d…

It seems to me that memory safety might be the difference between the software engineering and Software Engineering. As in, an actual Engineering discipline.

However, I should probably pipe down, as I would not call myself either one.

Re: Memory safety absolutists

#24

Post by [deleted] »

yjftsjthsd-h wrote: post #22

> But Rust is unsafe, isn't it? It has unsafe after all! If you want to be that strict, or in other words, if you are a memory safety absolutist, that may well be true for you. I, and I hope most people, am more pragmatic than that. So... Yes, Rust is less safe. Just that now the Rust apologist wants to back away from that and say that actually memory safety isn't actually the end all be all. C has a lot of security…

[deleted]

Re: Memory safety absolutists

#25

Post by jvuygbbkuurx »

yjftsjthsd-h wrote: post #22

> But Rust is unsafe, isn't it? It has unsafe after all! If you want to be that strict, or in other words, if you are a memory safety absolutist, that may well be true for you. I, and I hope most people, am more pragmatic than that. So... Yes, Rust is less safe. Just that now the Rust apologist wants to back away from that and say that actually memory safety isn't actually the end all be all. C has a lot of security…

Unsafe doesn't disable the borrow checker

Re: Memory safety absolutists

#26

Post by davidgay »

kmeisthax wrote: post #7

I was not aware of the antagonism from the Zig / Fil-C people to Rust, but it makes absolutely no sense. Like, of course you can prevent all memory safety errors by using a garbage collector. That has been known since the 90s. In fact, there was a good two decades after Java released where all the research on memory safety just stopped, because the standard answer became "use a GC". If you couldn't use GC, you were s…

> Like, of course you can prevent all memory safety errors by using a garbage collector. That has been known since the 90s.

No, it's been known since GC was invented.

> In fact, there was a good two decades after Java released where all the research on memory safety just stopped, because the standard answer became "use a GC".

Having done all of my research on memory safety after Java was released, I find this statement a little exaggerated... (e.g., https://barnowl.org/research/pubs/98-pldi-regions.pdf, https://barnowl.org/research/pubs/07-hotos-linux.pdf)

Re: Memory safety absolutists

#27

Post by yjftsjthsd-h »

jvuygbbkuurx wrote: post #25
yjftsjthsd-h wrote: post #22

> But Rust is unsafe, isn't it? It has unsafe after all! If you want to be that strict, or in other words, if you are a memory safety absolutist, that may well be true for you. I, and I hope most people, am more pragmatic than that. So... Yes, Rust is less safe. Just that now the Rust apologist wants to back away from that and say that actually memory safety isn't actually the end all be all. C has a lot of security…

Unsafe doesn't disable the borrow checker

I don't follow how that impacts the argument. Rust with unsafe is certainly safer than C, but I don't see that that changes anything at hand.

Re: Memory safety absolutists

#28

Post by IshKebab »

Repeat after me: Rust is not just memory safe C++!

Memory safety is a really big reason to use Rust, but it is very very far from the only reason. Even if Fil-C was magically zero-overhead (that is basically what CHERI is), I would still rather use Rust.

Rust has so many advantages over something like Fil-C it's hard to list them. I think Fil-C is a great project but it's only really relevant if you have no choice but to use C. If you can use Rust you also get:

* Compile time memory safety (Fil-C / CHERI are run-time).

* A modern functional-style type system (helps prevent logic bugs).

* Tree ownership (helps prevent logic bugs)

* Sane toolchain (helps prevent hair loss).

* Easy dependencies.

* Vastly more things checked at compile time.

Also I find it amusing how this post claimed it wasn't about Rust and then spent the whole time talking about it.

Rust is great. I don't think that really needs to be debated any more.

Re: Memory safety absolutists

#29

Post by saghm »

davidgay wrote: post #26
kmeisthax wrote: post #7

I was not aware of the antagonism from the Zig / Fil-C people to Rust, but it makes absolutely no sense. Like, of course you can prevent all memory safety errors by using a garbage collector. That has been known since the 90s. In fact, there was a good two decades after Java released where all the research on memory safety just stopped, because the standard answer became "use a GC". If you couldn't use GC, you were s…

> Like, of course you can prevent all memory safety errors by using a garbage collector. That has been known since the 90s. No, it's been known since GC was invented. > In fact, there was a good two decades after Java released where all the research on memory safety just stopped, because the standard answer became "use a GC". Having done all of my research on memory safety after Java was released, I find this stateme…

Yeah, my understanding (which is not from first-hand experience) is that a huge part of the origin of Rust was that there was a lot of research in memory safety techniques that had been going mostly unused by mainstream languages, so the idea was "Why not try to make a language using some of it?"
Post reply on HN