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

Borrow Checking, RC, GC, and Eleven Other Memory Safety Approaches

verdagon.dev

Post reply on HN
Print view View original

51–60 of 143 posts

Re: Borrow Checking, RC, GC, and Eleven Other Memory Safety Approaches

#51

Post by amelius »

3836293648 wrote: post #33
amelius wrote: post #27

I like many of the ideas of Rust, but I still think it is an unsuitable language for most projects. The problem is that it is very easy to write non-GC'd code in a GC'd language, but the other way around it is much much harder. Therefore, I think the fundamental choice of Rust to not support a GC is wrong.

You've got this one wrong. Rust is designed for a specific use case. Most projects are not that use case. Therefore the choice to use Rust is wrong. If GC is an option and you want all the nice parts of Rust, use OCaml

> If GC is an option and you want all the nice parts of Rust, use OCaml

So are you saying it would be possible to use a hypothetical "non-GC-enabled" OCaml compiler that complains if GC'd code is invoked/generated, and it would be a similar experience as using Rust?

Re: Borrow Checking, RC, GC, and Eleven Other Memory Safety Approaches

#52

Post by jakewins »

pizlonator wrote: post #49

The way you make garbage collection deterministic is not by doing regions but by making it concurrent. That’s increasingly common, though fully concurrent GCs are not as common as “sorta concurrent” ones because there is a throughput hit to going fully concurrent (albeit probably a smaller one than if you partitioned your heap as the article suggests). Also, no point in calling it “tracing garbage collection”. Its ju…

Do you have any recommended reading material on this?

Intuitively it feels like making it concurrent should do the opposite of making GC deterministic! I’d love to read something showing that intuition is wrong

Re: Borrow Checking, RC, GC, and Eleven Other Memory Safety Approaches

#53

Post by bluGill »

Why is garbage collection called memory safety? Garbage collection in whatever form is only memory safe if it doesn't free memory that will still be used. (which means if you actually get all your free calls correct C is memory safe - most long lived C code bases have been beat on enough that they get this right for even the obscure paths).

Use after free is important, but in my experience not common and not too hard to track down when it happens (maybe I'm lucky? - we generally used a referenced counted GC for the cases where ownership is hard to track down in C++)

I'm more worried about other issues of memory safety that are not addressed: write into someone else's buffer - which is generally caused by write off the end of your buffer.

Re: Borrow Checking, RC, GC, and Eleven Other Memory Safety Approaches

#54

Post by nemaar »

kibwen wrote: post #41
DanielHB wrote: post #20

I am not experienced with rust and borrow checkers, but my impression is that borrow checkers also statically ensures thread/async safety while most other memory safety systems don't. Is this accurate?

The borrow checker is only one component of the means by which Rust statically enforces thread safety. If you design a language that doesn't allow pointers to be shared across threads at all, then you wouldn't need a borrow checker. Likewise if you have an immutable-only language. What's interesting about Rust is that it actually supports this safely, which is still unbelievable sometimes (like being able to send ref…

> If you design a language that doesn't allow pointers to be shared across threads at all, then you wouldn't need a borrow checker.

Is that actually true? I'm pretty sure you need the borrow checker even for single threaded Rust to prevent use after frees.

Re: Borrow Checking, RC, GC, and Eleven Other Memory Safety Approaches

#55

Post by amelius »

3836293648 wrote: post #33
amelius wrote: post #27

I like many of the ideas of Rust, but I still think it is an unsuitable language for most projects. The problem is that it is very easy to write non-GC'd code in a GC'd language, but the other way around it is much much harder. Therefore, I think the fundamental choice of Rust to not support a GC is wrong.

You've got this one wrong. Rust is designed for a specific use case. Most projects are not that use case. Therefore the choice to use Rust is wrong. If GC is an option and you want all the nice parts of Rust, use OCaml

> Most projects are not that use case. Therefore the choice to use Rust is wrong.

Do you think that projects that have a large GUI component should be written in Rust?

What if a project has both a "systems" and a GUI component to it?

Re: Borrow Checking, RC, GC, and Eleven Other Memory Safety Approaches

#56

Post by pizlonator »

jakewins wrote: post #52
pizlonator wrote: post #49

The way you make garbage collection deterministic is not by doing regions but by making it concurrent. That’s increasingly common, though fully concurrent GCs are not as common as “sorta concurrent” ones because there is a throughput hit to going fully concurrent (albeit probably a smaller one than if you partitioned your heap as the article suggests). Also, no point in calling it “tracing garbage collection”. Its ju…

Do you have any recommended reading material on this? Intuitively it feels like making it concurrent should do the opposite of making GC deterministic! I’d love to read something showing that intuition is wrong

Garbage collection handbook

https://gchandbook.org/

If you want to see my latest concurrent GC, see

https://github.com/pizlonator/llvm-project-deluge/blob/delug...

https://github.com/pizlonator/llvm-project-deluge/blob/delug...

Re: Borrow Checking, RC, GC, and Eleven Other Memory Safety Approaches

#57

Post by roetlich »

pizlonator wrote: post #49

The way you make garbage collection deterministic is not by doing regions but by making it concurrent. That’s increasingly common, though fully concurrent GCs are not as common as “sorta concurrent” ones because there is a throughput hit to going fully concurrent (albeit probably a smaller one than if you partitioned your heap as the article suggests). Also, no point in calling it “tracing garbage collection”. Its ju…

> Also, no point in calling it “tracing garbage collection”.

You're against more explicit naming just for the sake of it? In the literature reference counting is also referred to as a type of garbage collection, and doesn't involve tracing. If you talking about a specific context you can probably drop the "tracing", but in a general article like this it would just be very confusing?

This way, someone can google "tracing garbage collection", and will find the relevant wikipedia article: https://en.wikipedia.org/wiki/Tracing_garbage_collection

Re: Borrow Checking, RC, GC, and Eleven Other Memory Safety Approaches

#58

Post by azornathogron »

pizlonator wrote: post #49

The way you make garbage collection deterministic is not by doing regions but by making it concurrent. That’s increasingly common, though fully concurrent GCs are not as common as “sorta concurrent” ones because there is a throughput hit to going fully concurrent (albeit probably a smaller one than if you partitioned your heap as the article suggests). Also, no point in calling it “tracing garbage collection”. Its ju…

Using concurrent GC has various advantages but in no way makes it deterministic.

Re: Borrow Checking, RC, GC, and Eleven Other Memory Safety Approaches

#59

Post by chlorion »

nemaar wrote: post #54
kibwen wrote: post #41

Earlier quoted context omitted.

The borrow checker is only one component of the means by which Rust statically enforces thread safety. If you design a language that doesn't allow pointers to be shared across threads at all, then you wouldn't need a borrow checker. Likewise if you have an immutable-only language. What's interesting about Rust is that it actually supports this safely, which is still unbelievable sometimes (like being able to send ref…

> If you design a language that doesn't allow pointers to be shared across threads at all, then you wouldn't need a borrow checker. Is that actually true? I'm pretty sure you need the borrow checker even for single threaded Rust to prevent use after frees.

Theres even more than just UAFs that you have to worry about in a single threaded context, but yes you are correct.

Here's a good post that talks about why shared mutability even in single threaded contexts is dangerous: https://manishearth.github.io/blog/2015/05/17/the-problem-wi...

Re: Borrow Checking, RC, GC, and Eleven Other Memory Safety Approaches

#60

Post by pizlonator »

roetlich wrote: post #57
pizlonator wrote: post #49

The way you make garbage collection deterministic is not by doing regions but by making it concurrent. That’s increasingly common, though fully concurrent GCs are not as common as “sorta concurrent” ones because there is a throughput hit to going fully concurrent (albeit probably a smaller one than if you partitioned your heap as the article suggests). Also, no point in calling it “tracing garbage collection”. Its ju…

> Also, no point in calling it “tracing garbage collection”. You're against more explicit naming just for the sake of it? In the literature reference counting is also referred to as a type of garbage collection, and doesn't involve tracing. If you talking about a specific context you can probably drop the "tracing", but in a general article like this it would just be very confusing? This way, someone can google "trac…

The literature does not always put the “tracing” in front of the “garbage collection”.

For example, nobody says that Objective-C is garbage collected just because it has ARC. Nobody says that C++ is garbage collected even though shared_ptr is widespread. And systems that do tracing GC just call it GC (see for example https://www.oracle.com/webfolder/technetwork/tutorials/obe/j...)

To think clearly about the tradeoff between GC and RC it’s important to acknowledge the semantic differences:

- GC definitely collects dead cycles.

- RC knows exactly when objects die, which allows for sensible destructor semantics and things like CoW.

- it’s possible to use RC as an optimization in a GC, but then you end up with GC semantics and you still have tracing (hence: if it’s got tracing, it’s a garbage collector).

It’s a recent fad to say that RC is a kind of GC, but I don’t think it ever took off outside academia. Folks who write GCs call them GCs. Folks who do shared_ptr or ARC say that they don’t use GC.

And its good if this fad dies because saying that RC is a kind of GC causes folks to overlook the massive semantic elephant in the room: if you use a GC then you can’t swap it for RC because you’d leak memory (RC would fail to delete cycles), and if you use RC and swap it for a GC then you’d leak resources (your destructors would no longer get called when you expect them to).

On the other hand, it is possible to change the guts of an RC impl without anyone noticing. And it’s possible to change the guts of a GC while preserving compatibility. So these are really two different worlds.

Post reply on HN