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

61–70 of 85 posts

Re: Garbage collection without unsafe code

#61

Post by pjmlp »

bigbadfeline wrote: post #52
pjmlp wrote: post #28

Earlier quoted context omitted.

I certainly do, which is why outside some hobby coding to try out new language features, as means to understand where Rust stands, I don't have any special use case where I would pick Rust instead of one of those languages. For me its ideal use case, are places where any form of automated resource management is either not technically possible, or it is a waste of time trying to change mindsets.

> I don't have any special use case where I would pick Rust instead of one of those languages. Rust isn't a language for a special case, Rust is universal. Those other languages are for special cases, you're simply a special case developer. Picking a different language for each special case is the primary problem Rust solves, it's the problem of being a jack of all trades and a master of none. >> If anything all thos…

When every problem looks like a nail...

The proof is the amount of research that is ongoing for plenty of people that don't consider Rust as it stands today, the ultimate answer in programming languages, including people like Niko Matsakis.

Or are you going to reply his opinion has no value, and should abandon the language ergonomic proposals from the improvements roadmap?

Re: Garbage collection without unsafe code

#62

Post by mayhemducks »

quotemstr wrote: post #18
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?

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.

I guess I like the idea of having to think a little more deeply about how memory is used while I'm programming. I know that might sound a bit odd, but before I started learning and using rust, I remember being much less aware of certain things while programming, and then discovering much later that I did something very sub-optimally. So rust is kind of a forcing function in a way - it makes me write better code.

I have also worked on projects (web apps) where GC pauses became annoying to end-users. I wouldn't say this is the fault of GC perse, but writing code without a GC, seems to prevent some performance problems for me, and can also make performance problems stand out sooner in the dev cycle.

Re: Garbage collection without unsafe code

#63

Post by pjmlp »

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?

Lock free data structures are one example of a scenario that is easier to implement with GCs.

Re: Garbage collection without unsafe code

#64

Post by bigbadfeline »

pjmlp wrote: post #61
bigbadfeline wrote: post #52

Earlier quoted context omitted.

> I don't have any special use case where I would pick Rust instead of one of those languages. Rust isn't a language for a special case, Rust is universal. Those other languages are for special cases, you're simply a special case developer. Picking a different language for each special case is the primary problem Rust solves, it's the problem of being a jack of all trades and a master of none. >> If anything all thos…

When every problem looks like a nail... The proof is the amount of research that is ongoing for plenty of people that don't consider Rust as it stands today, the ultimate answer in programming languages, including people like Niko Matsakis. Or are you going to reply his opinion has no value, and should abandon the language ergonomic proposals from the improvements roadmap?

> Or are you going to reply his opinion has no value, and should abandon the language ergonomic proposals from the improvements roadmap?

I don't deny the existence of special cases or the value of looking for better ergonomics even at the expense of university. However, at the moment Rust is the best option for practitioners who don't have enough time to juggle multiple languages.

Re: Garbage collection without unsafe code

#65

Post by adrian_b »

oersted wrote: post #48
zozbot234 wrote: post #39

Earlier quoted context omitted.

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

Bugs in the use of indexes can corrupt memory only inside the corresponding array, they cannot corrupt arbitrary memory locations, like pointers.

Such a corrupted array should never cause a program crash, unless there is a second bug where unexpected values in the corrupted array can cause crashes or unless it is intended that any detected bug must abort the program, when it does not matter whether pointers or indexes were used.

Thus using indexes should always be safer than using pointers.

In modern CPUs, indexed addressing is as fast as addressing through a register that holds a pointer, which removes the main reason why pointers were preferred in the seventies of the last century, by the time of the C language design, when in most minicomputers and microcomputers using pointers was faster than using indexes.

Re: Garbage collection without unsafe code

#66

Post by adastra22 »

rurban wrote: post #53
adastra22 wrote: post #37

Earlier quoted context omitted.

I don’t know what your point is. Unsafe blocks in the stdlib isn’t a gotcha. It’s the whole point of unsafe: you provide a validated and ideally proveably correct implementation once, with a safe wrapper. It’s how everything is implemented under the hood. It’s like double entry accounting when you only have one pen and one writing hand. The system is broken if you ever write down only half of a transaction in one led…

So you are fine in calling a language "safe", when it has unsafe blocks, which the compiler skips to check? You have to that manually, and then you are back in C++ land. That's hilarious. You can call it somewhat safe, or mostly safe, but never safe.

The perfectly safe platonic ideal you are implying cannot exist. Rust is a safe language because it bounds the unsafely to the minimal, clearly demarcated area where it can be reviewed and proven (outside the bounds of the type system) to hold.

That is not "back in C++ land."

Re: Garbage collection without unsafe code

#67

Post by kibwen »

pjmlp wrote: post #60
kibwen wrote: post #54

Earlier quoted context omitted.

> it is better having automated resource management Rust's ownership system is automated resource management. What you're asking for is dynamic lifetime determination, which Rust provides via types that opt out of the hierarchical single-ownership paradigm.

Nope, because it has plenty of manual hand holding to keep the compiler happy.

Manual memory management requires the programmer to insert calls to free at specific points in the program. That's manual static lifetime determination. A traditional garbage collector uses runtime analysis to determine when it's safe to call free. That's automatic dynamic lifetime determination. What Rust does is automatic static lifetime determination. Designing your data structures such that they're acyclic is not what anyone means when they say "manual memory management".

Re: Garbage collection without unsafe code

#68

Post by oersted »

adrian_b wrote: post #65
oersted wrote: post #48

Earlier quoted context omitted.

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

Bugs in the use of indexes can corrupt memory only inside the corresponding array, they cannot corrupt arbitrary memory locations, like pointers. Such a corrupted array should never cause a program crash, unless there is a second bug where unexpected values in the corrupted array can cause crashes or unless it is intended that any detected bug must abort the program, when it does not matter whether pointers or indexe…

Here OP is implementing a full allocator and something close to a new abstract layer of virtual memory backed by vectors and addressed by offsets.

For some use-cases, you will probably keep all dynamically allocated objects in this memory.

At that point you have circumvented most of Rust’s protections and ergonomics. The user will effectively be working with raw pointers into this memory. The implementation itself also doesn’t have the proper checks because it is manipulating indexes instead of pointers.

The post itself notes around the end how it is fairly easy to end up with a dangling pointer or one that points to a different object allocated to the same position after the old one was freed. It also has quite a few places where it can panic. And implementing its Trace trait wrong or not using Roots as intended can have complex consequences. And all that while feeling like this is the most safe GC because it has no unsafe.

I don’t disagree with anything you said, and I also quite like the work from OP. But I hope you can see that this is not fully aligned with Rust’s philosophy.

Re: Garbage collection without unsafe code

#69

Post by rurban »

adastra22 wrote: post #66
rurban wrote: post #53

Earlier quoted context omitted.

So you are fine in calling a language "safe", when it has unsafe blocks, which the compiler skips to check? You have to that manually, and then you are back in C++ land. That's hilarious. You can call it somewhat safe, or mostly safe, but never safe.

The perfectly safe platonic ideal you are implying cannot exist. Rust is a safe language because it bounds the unsafely to the minimal, clearly demarcated area where it can be reviewed and proven (outside the bounds of the type system) to hold. That is not "back in C++ land."

The perfectly safe ideal does exist and is called safe. Calling unsafe safe is not even Sophism, it is mere lying

Re: Garbage collection without unsafe code

#70

Post by rurban »

kibwen wrote: post #55
rurban wrote: post #41

Earlier quoted context omitted.

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

You've made it clear from this thread that you have no idea what you're talking about. Please do not waste our time by commenting on this topic further.

Ha, I did maintain two safe languages. How many did you?
Post reply on HN