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

71–80 of 143 posts

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

#71

Post by jerf »

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.

You may have to define your terms more carefully and extend past "doesn't allow pointers", but it can be true. Look to Erlang; the key to Erlang's safety isn't actually its immutable values, but the fact that no messages can travel between the various "processes" (threads in conventional parlance, just not "OS threads") that carry any sort of reference or pointer is what makes it so Erlang is safe without any concept of borrow checking. It also semantically copies all values (there are some internal optimizations for certain types of values that make it so they are technically not copied, but at the language level, it's all copies) and each process is GC'd, so in terms of the Rust borrow checker I mention this only in the context of cross-thread sharing safety.

But in general, if threads can't communicate any sort of pointer or reference that allows direct, unmediated access to the same value that some other thread will see, there's no need for a "borrow checker" for thread safety.

(Note that "but what if I have a thing that is just a token for a value that people can potentially read and write from anywhere?" is not an exception to this, because in this context, such access would not be unmediated. This access would still require messages to and from the "holding" process. This sort of safety won't stop you from basically deliberately re-embedding your own new sorts of races and unsafe accesses in at the higher level of your own code, it just won't be a data race in the same way that multiple threads reading and writing through the same pointer is a data race at the lower level. The main solution to this problem is "Doctor, it hurts when I do this." -> "Don't do that.")

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

#72

Post by roetlich »

pizlonator wrote: post #66
roetlich wrote: post #65

Earlier quoted context omitted.

> The literature does not always put the “tracing” in front of the “garbage collection”. Not always, but often enough that an introductory article that presents an overview of different memory managment techniques should maybe use the longer name to avoid confusion. And I kinda agree with you, using the name "garbage collection" for RC doesn't really make sense, there is no metaphorical garbage truck driving around t…

> Not always, but often enough that an introductory article that presents an overview of different memory managment techniques should maybe use the longer name to avoid confusion. Referring to garbage collection as tracing garbage collection creates more confusion and should be avoided. It confuses folks into thinking that there is some garbage collection that isn’t tracing. There’s no such thing. > What's your opini…

> And it’s not perf considerations if it’s the difference between your program running at all and crashing.

Yeah, that's what I meant to include by "behave very differently". I don't think we disagree on anything technical here. The problem is if you are currently googling for garbage collection you will mostly get garbage results. Here's duckduckgo to avoid my search bubble: https://duckduckgo.com/?q=garbage+collection+programming

The first result is the wikipedia article: https://en.wikipedia.org/wiki/Garbage_collection_%28computer... It's pretty bad, under "Strategies" it lists three: Tracing, Reference Counting and Escape Analysis. I'm sure these three are similar things.

The second result is this blog post, also listing rereference counting as gc: https://www.freecodecamp.org/news/a-guide-to-garbage-collect...

And the third result looks okay. Searching for "tracing garbage collection" has better results. The text in question already uses "gc" most of the time, and has a footnote saying:

> By "garbage collection", we're referring to tracing garbage collection.

I think that's as clear as it gets, without going on rant about the names of things. You are clearly an expert in garbage collectors, but most people in the target audience of that article are not. The article compares the differences between rc and gc. If someone then goes and reads the wikipedia articles about either of those they will be very confused because wikipedia will tell them rc is gc. A "fad" like this can't be undone, once a usage of a word becomes this popular you can't undo it.

Okay, sorry, this was too long, and we agree to like 99% anyway. Have a nice day! :)

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

#73

Post by constantcrying »

the__alchemist wrote: post #62

After pondering, my single favorite capability of rust is this: fn modify(val: &mut u8) { // ... } No other language appears to have this seemingly trivial capability; their canonical alternatives are all, IMO, clumsier. In light of the article, is this due to Rust's memory model, or an unrelated language insight?

How is a mutable reference as an argument to a function in any way unique? C++ has mutable references as arguments to functions.

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

#74

Post by constantcrying »

xmcqdpt2 wrote: post #42

Not a fan of the framing of the article. Firstly, there are millions of Mayans alive today, https://en.wikipedia.org/wiki/Maya_peoples and secondly, the reason why the pre-Colombian cultural texts and script are not in use today, even by the people who speak the 28 Mayan languages currently in use, is because of genocide by Columbus and those that followed. The Catholic church destroyed every piece of Mayan script th…

I thought it was just annoying to read. Irrelevant analogies never helped me understand anything.

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

#75

Post by constantcrying »

bluGill wrote: post #53

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…

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

Yes. A garbage collector is only safe if it works correctly. What an irrelevant observation. Nothing can guarantee that something works correctly if it doesn't work correctly.

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

#76

Post by the__alchemist »

constantcrying wrote: post #73
the__alchemist wrote: post #62

After pondering, my single favorite capability of rust is this: fn modify(val: &mut u8) { // ... } No other language appears to have this seemingly trivial capability; their canonical alternatives are all, IMO, clumsier. In light of the article, is this due to Rust's memory model, or an unrelated language insight?

How is a mutable reference as an argument to a function in any way unique? C++ has mutable references as arguments to functions.

You're right; you can do this in C++, although the patterns I've seen usually involve pointers.

There is no equivalent in Python, Javascript, Typescript, Java, or Kotlin.

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

#77

Post by pizlonator »

roetlich wrote: post #72
pizlonator wrote: post #66

Earlier quoted context omitted.

> Not always, but often enough that an introductory article that presents an overview of different memory managment techniques should maybe use the longer name to avoid confusion. Referring to garbage collection as tracing garbage collection creates more confusion and should be avoided. It confuses folks into thinking that there is some garbage collection that isn’t tracing. There’s no such thing. > What's your opini…

> And it’s not perf considerations if it’s the difference between your program running at all and crashing. Yeah, that's what I meant to include by "behave very differently". I don't think we disagree on anything technical here. The problem is if you are currently googling for garbage collection you will mostly get garbage results. Here's duckduckgo to avoid my search bubble: https://duckduckgo.com/?q=garbage+collect…

That reminds me of the time I went on a first date and she asked, "so what do you do exactly?" and I said I work on "garbage collection". You should have seen her face!

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

#78

Post by constantcrying »

the__alchemist wrote: post #76
constantcrying wrote: post #73

Earlier quoted context omitted.

How is a mutable reference as an argument to a function in any way unique? C++ has mutable references as arguments to functions.

You're right; you can do this in C++, although the patterns I've seen usually involve pointers. There is no equivalent in Python, Javascript, Typescript, Java, or Kotlin.

>I've seen usually involve pointers.

If only C++ had a thing called "references", which conveniently also used the "&" symbol and are a way to do exactly this without pointers.

https://en.cppreference.com/w/cpp/language/reference

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

#79

Post by the__alchemist »

constantcrying wrote: post #78
the__alchemist wrote: post #76

Earlier quoted context omitted.

You're right; you can do this in C++, although the patterns I've seen usually involve pointers. There is no equivalent in Python, Javascript, Typescript, Java, or Kotlin.

>I've seen usually involve pointers. If only C++ had a thing called "references", which conveniently also used the "&" symbol and are a way to do exactly this without pointers. https://en.cppreference.com/w/cpp/language/reference

I stand corrected on C++. Can you think of any other languages? Of the ones I listed, I use all of, and am continuously frustrated by this limitation.

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

#80

Post by constantcrying »

the__alchemist wrote: post #79
constantcrying wrote: post #78

Earlier quoted context omitted.

>I've seen usually involve pointers. If only C++ had a thing called "references", which conveniently also used the "&" symbol and are a way to do exactly this without pointers. https://en.cppreference.com/w/cpp/language/reference

I stand corrected on C++. Can you think of any other languages? Of the ones I listed, I use all of, and am continuously frustrated by this limitation.

>Can you think of any other languages?

Yes. E.g. every language where you can pass pointers can do this. Reference are a construct around pointers.

>Of the ones I listed, I use all of, and am continuously frustrated by this limitation.

Why? This is only a limitation for a few basic types. All the language you mention allow you to modify objects passed to a function.

If it ever were any issue though you can always return the modified object and overwrite the original.

a = modify(a)

works even if you can only pass a value.

In practice this should never be a limitation, certainly I have never encountered it as one.

Post reply on HN