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

11–20 of 85 posts

Re: Garbage collection without unsafe code

#11

Post by rurban »

bayesnet wrote: post #8
rurban wrote: post #6

Oh oh, who would have thought. A memory-safe rust at last. With no unsafe allowed, even type safe. Unless you forget about their type bugs: https://github.com/Speykious/cve-rs . So maybe eliminate type and concurrency unsafeties also then in the next decades or so.

The existence of a soundness bug in the typechecker doesn’t refute the value of soundness as a language design contract. If anything it’s the opposite: issues demonstrated by cve-rs are _language bugs_ and are _fixable_ in principle. “Safe Rust should be memory-safe” is a well-defined, falsifiable contract that the compiler can be measured against. Meanwhile memory unsafety is a feature of the semantics of C++ and so…

The language design contract is unsafe by default. In memory, types and concurrency. What are you talking about? There are unsafe blocks all over the stdlib. And concurrency safety would need to get rid of their blocking IO, which they haven't even acknowledged.

Re: Garbage collection without unsafe code

#12

Post by pjmlp »

swiftcoder wrote: post #5

This is a very neat proof of concept that the problem is solvable entirely in safe rust. Obviously the ergonomics suffer, but its an interesting datapoint, and one can hope that future rust developments will mitigate some of the papercuts

Given your nick, one of the points of 2026 roadmap is exactly trying to make Rust more Swift like, or any other language with RC as automatic resource mechanism for that matter, removing the .clone() pain.

Or the experiements Niko Matsakis is doing with Dada.

Re: Garbage collection without unsafe code

#13

Post by pjmlp »

rurban wrote: post #6

Oh oh, who would have thought. A memory-safe rust at last. With no unsafe allowed, even type safe. Unless you forget about their type bugs: https://github.com/Speykious/cve-rs . So maybe eliminate type and concurrency unsafeties also then in the next decades or so.

It is called OCaml, for those that want it.

Re: Garbage collection without unsafe code

#15

Post by Arch485 »

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?

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.

Re: Garbage collection without unsafe code

#16

Post by mayhemducks »

Arch485 wrote: post #15
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?

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 genuinely curious about what it lets me do better/faster within rust.

Re: Garbage collection without unsafe code

#17

Post by quotemstr »

pjmlp wrote: post #9
ltratt wrote: post #7

It would really be good if someone could provide an updated overview of all of the "GCs for Rust" created thus far -- for a while I tried to keep up with them, but there are just too many! When we wrote the Alloy paper, we took Manish's survey as a starting point, and covered as many GCs of different kinds as we could squeeze in [1]. But even then there was no way we could squeeze _everything_ in, and I've seen at le…

If anything all those attempts prove that for many scenarios, it is better having automated resource management + (affine, linear, dependent, effects) than the pure affine types approach taken by Rust. Hence all the Chapel, Swift, D, Linear Haskel, Ox, Idris2, Scala Capture Checking, Koka, and probably many others, efforts going on. This is also noticeable among rustaceans, otherwise ergonomics for all the .clone() a…

If you want automated resource management, automate it. I'm really not convinced that Koka-style effects-for-everything are a win relative to just passing objects that own resources through parameters so they have actual values and explicit lifetimes.

Re: Garbage collection without unsafe code

#18

Post by quotemstr »

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.

Re: Garbage collection without unsafe code

#19

Post by quotemstr »

rurban wrote: post #11
bayesnet wrote: post #8

Earlier quoted context omitted.

The existence of a soundness bug in the typechecker doesn’t refute the value of soundness as a language design contract. If anything it’s the opposite: issues demonstrated by cve-rs are _language bugs_ and are _fixable_ in principle. “Safe Rust should be memory-safe” is a well-defined, falsifiable contract that the compiler can be measured against. Meanwhile memory unsafety is a feature of the semantics of C++ and so…

The language design contract is unsafe by default. In memory, types and concurrency. What are you talking about? There are unsafe blocks all over the stdlib. And concurrency safety would need to get rid of their blocking IO, which they haven't even acknowledged.

> There are unsafe blocks all over the stdlib

Physics is unsafe. Something, somewhere needs to provide the safe core.

> And concurrency safety would need to get rid of their blocking IO, which they haven't even acknowledged.

Is your position that blocking IO can't be compatible with concurrency safety? That's a strange claim. Can you explain?

Re: Garbage collection without unsafe code

#20

Post by marcosscriven »

rurban wrote: post #6

Oh oh, who would have thought. A memory-safe rust at last. With no unsafe allowed, even type safe. Unless you forget about their type bugs: https://github.com/Speykious/cve-rs . So maybe eliminate type and concurrency unsafeties also then in the next decades or so.

I see you’ve been downvoted, but honestly this is news to me.

I see that repo is two years old - are there flaws in Rust that aren’t edge cases that would make it not memory safe?

Post reply on HN