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

Garbage collection without unsafe code

fitzgen.com

Post reply on HN
Print view View original

41–50 of 85 posts

Re: Garbage collection without unsafe code

#41

Post by rurban »

aw1621107 wrote: post #35
rurban wrote: post #24

Earlier quoted context omitted.

Sure, but then they shout all over how safe they are. They got rid of the safeties pretty late, when they ripped out their GC, but kept their false promises all over. No, that's common knowledge. I fixed concurrency safety by forbidding blocking IO. Others also. Maybe there are other ways, but never heard of other ways.

> They got rid of the safeties pretty late, when they ripped out their GC, but kept their false promises all over. This seems like a non-sequitur to me? The presence/absence of a GC is not dispositive with respect to determining "safety", especially when the GC itself involves unsafe code.

Have you ever seen a GC system with memory unsafeties? I cannot remember any

Re: Garbage collection without unsafe code

#42

Post by afdbcreid »

oersted wrote: post #33

Frankly, it always feels a bit wrong to me to get around Rust's strictness for pointers by just replacing them with IDs/indexes/offsets into some collection. You can still have many of the same memory-safety issues as with pointers, except that now they become logic bugs that are undetectable by the compiler. Either use unsafe and think about using raw pointers carefully, respecting the soundness rules, or truly rede…

If we compare 1-to-1 indices to unsafe code, indices always win (assuming they are viable wrt. perf etc.). This is very simple: all else being equal, a mistake in unsafe code (can be) UB while a mistake in indices is at most a logic bug, and logic bug is always preferred to UB.

Of course, it does mean we should compare them 1-to-1, which means we should treat the indices code like we would treat unsafe code. The most important conclusion is to encapsulate it in a data structure without business logic.

Re: Garbage collection without unsafe code

#43

Post by WorldMaker »

mayhemducks wrote: post #16
Arch485 wrote: post #15

Earlier quoted context omitted.

I've never really had the urge to use GC in Rust, but if I were to speculate, I'd say easier cyclic references would be one benefit. And depending on the specific GC implementation, you can probably get around many of Rust's ownership rules because Gc pointers are usually `Copy`, so you can pass things around everywhere and not think about references/ownership as much.

Okay I could see that - like implementing linked lists would be easier yeah? I just feel like not having GC is sort of a deliberate, core design choice for the language. Having strict ownership rules and being forced to think about references feels like a feature not a bug you know? Adding GC feels analogous to the "++" in C++ to me. Not that I have anything against the efforts people are putting into it though - I'm…

GC is a similar but different set of strict ownership rules (and its own versions of being forced to think about reference invariants). There's an inherently interesting Venn Diagram overlap between Rust borrow mechanics and GC, they aren't entirely separate worlds. They are more like related worlds with slightly different trade-offs. (Similarly there's C# and .NET actively exploring GC-safe relatives of Rust's borrow mechanics in Memory/Span space right now, to great effect.)

In terms of practical, yeah a doubly linked list (or trees with bidirectional pointers to both parent and children, etc) is especially easier to implement in a GC environment than with Rust borrow checking alone. You can do it without a GC, but a GC can be a helpful intermediary.

Re: Garbage collection without unsafe code

#44

Post by Weebs »

mayhemducks wrote: post #14

I really like rust because it does NOT have garbage collection. Can someone smarter than me help me understand the benefits of having GC in rust specifically? Does it enable things that are more difficult in "non GC" rust?

Certain algorithms are a lot easier. It's not needed though

Re: Garbage collection without unsafe code

#45

Post by afdbcreid »

rurban wrote: post #41
aw1621107 wrote: post #35

Earlier quoted context omitted.

> They got rid of the safeties pretty late, when they ripped out their GC, but kept their false promises all over. This seems like a non-sequitur to me? The presence/absence of a GC is not dispositive with respect to determining "safety", especially when the GC itself involves unsafe code.

Have you ever seen a GC system with memory unsafeties? I cannot remember any

Ah. I believe pretty much every safe language on the planet constantly has bugs in the implementation that can be exploited to cause unsafety. Sometimes they even get CVEs, e.g. in JavaScript VMs.

Re: Garbage collection without unsafe code

#46

Post by Someone »

jandrewrogers wrote: post #38
quotemstr wrote: post #18

Earlier quoted context omitted.

Why do you like managing your own memory exactly? Modern GCs are quite good, so the domain in which you can beat their performance is narrow and will continue getting narrower as time goes on.

The software performance gap between modern GC code and non-GC code is still pretty large almost everywhere. GCs make entire classes of optimization effectively impossible. At the limit, GCs are an abstraction that is always going to make worse runtime choices than purpose-built code. GCs are useful in the same way that Python is useful even though it is slow. Simplicity of use has intrinsic value but that is a trade…

> At the limit, GCs are an abstraction that is always going to make worse runtime choices than purpose-built code.

You can say the same about any abstraction, such as having a generic memory allocator, using a standard library, actually about any code reuse. For example, many programs use printf, but don’t need all its features, so hand-rolling a custom version may lead to smaller, faster code (things get complicated here on systems with shared libraries)

The question always is whether lost performance (execution time, memory usage) is worth faster development.

Re: Garbage collection without unsafe code

#47

Post by kccqzy »

afdbcreid wrote: post #42
oersted wrote: post #33

Frankly, it always feels a bit wrong to me to get around Rust's strictness for pointers by just replacing them with IDs/indexes/offsets into some collection. You can still have many of the same memory-safety issues as with pointers, except that now they become logic bugs that are undetectable by the compiler. Either use unsafe and think about using raw pointers carefully, respecting the soundness rules, or truly rede…

If we compare 1-to-1 indices to unsafe code, indices always win (assuming they are viable wrt. perf etc.). This is very simple: all else being equal, a mistake in unsafe code (can be) UB while a mistake in indices is at most a logic bug, and logic bug is always preferred to UB. Of course, it does mean we should compare them 1-to-1, which means we should treat the indices code like we would treat unsafe code. The most…

Yeah but logic bugs cannot be found by tools. Whereas for UB at least we have address sanitizer and UB sanitizer and valgrind and many similar tools. You can recreate what these tools do in your API, and that’s extra work: a use-after-free bug may be easily detected by these tools, but when you are managing indices yourself, you may have to add assertions yourself to check for things that are logically deleted but not actually deleted.

Re: Garbage collection without unsafe code

#48

Post by oersted »

zozbot234 wrote: post #39
oersted wrote: post #33

Frankly, it always feels a bit wrong to me to get around Rust's strictness for pointers by just replacing them with IDs/indexes/offsets into some collection. You can still have many of the same memory-safety issues as with pointers, except that now they become logic bugs that are undetectable by the compiler. Either use unsafe and think about using raw pointers carefully, respecting the soundness rules, or truly rede…

Logic bugs are not memory safety issues, they're logic bugs. They cannot result in undefined behavior for the program as a whole, at least in the absence of unsafe code.

As far as I understand, memory safety goes well beyond undefined behavior. It’s a loose term including common pointer manipulation, allocation/deallocation and data-race issues.

Other than UB, using indexes instead of pointers can be exactly as error-prone and leads to the same kind of unexpected runtime crashes, memory corruption and security issues. It’s a false sense of security.

If you inspect the OP implementation in detail, you’ll notice that it is still plenty open to use-after-free bugs and lots of places where it can panic in an equivalent way to a segmentation fault.

It is quite unsafe while not being “unsafe”.

Re: Garbage collection without unsafe code

#49

Post by rurban »

afdbcreid wrote: post #45
rurban wrote: post #41

Earlier quoted context omitted.

Have you ever seen a GC system with memory unsafeties? I cannot remember any

Ah. I believe pretty much every safe language on the planet constantly has bugs in the implementation that can be exploited to cause unsafety. Sometimes they even get CVEs, e.g. in JavaScript VMs.

I don't do Javascript, but any self-respecting language which calls itself safe is actually safe. I worked for decades in actually memory and type safe languages, and never ever heard of a memory or type safety bug.

Just not the cheaters: Rust, Java (until recently), and of course Javascript with its unsafe implementations.

Memory safety bug in a proper lisp? Unheard of, unless you break the GC or do wrong FFI calls.

Re: Garbage collection without unsafe code

#50

Post by nitwit005 »

Someone wrote: post #46
jandrewrogers wrote: post #38

Earlier quoted context omitted.

The software performance gap between modern GC code and non-GC code is still pretty large almost everywhere. GCs make entire classes of optimization effectively impossible. At the limit, GCs are an abstraction that is always going to make worse runtime choices than purpose-built code. GCs are useful in the same way that Python is useful even though it is slow. Simplicity of use has intrinsic value but that is a trade…

> At the limit, GCs are an abstraction that is always going to make worse runtime choices than purpose-built code. You can say the same about any abstraction, such as having a generic memory allocator, using a standard library, actually about any code reuse. For example, many programs use printf , but don’t need all its features, so hand-rolling a custom version may lead to smaller, faster code (things get complicate…

You're making a new argument that's entirely different than the one they're responding to.
Post reply on HN