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

21–30 of 85 posts

Re: Garbage collection without unsafe code

#21

Post by swiftcoder »

pjmlp wrote: post #12
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.

> Given your nick

Weirdly, I picked this screen name about a decade before Swift the language (and several years before Swift the singer) debuted

Re: Garbage collection without unsafe code

#22

Post by ameliaquining »

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?

To give one trivial example, if you want to write an interpreter for a garbage-collected language in Rust, you need some kind of garbage-collection facility. You could in theory do it C-style by just using raw mostly-untyped pointers everywhere, but this defeats most of the benefit of Rust over C, so you might instead prefer to encapsulate the GC into its own library, so that you can use regular Rust idioms in all the parts of the code that aren't specifically about GC.

More generally, there are various situations where garbage collection is effectively a requirement: namely, when you've got a mutable graph where anything can point to anything else, where some nodes are root nodes and others are not, and so it's possible for cycles of unreachable nodes to occur and you don't want this to result in memory leaks.

You could in theory imagine a language like Rust where garbage collection was integrated more deeply on a syntactic level, such that you might sometimes use it for convenience and not just where it's a requirement (and Rust in fact worked like this for a while pre-1.0), but the way things currently work, integrating a garbage-collection library basically always makes your code more unwieldy and you only do it if you have to.

Re: Garbage collection without unsafe code

#23

Post by rurban »

marcosscriven wrote: post #20
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?

Sure, besides those bugs, read the specs. unsafe blocks. Loud and clear. worse than in Java where the unsafeties were just in a hidden sun class.

Re: Garbage collection without unsafe code

#24

Post by rurban »

quotemstr wrote: post #19
rurban wrote: post #11

Earlier quoted context omitted.

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?

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.

Re: Garbage collection without unsafe code

#25

Post by quotemstr »

rurban wrote: post #24
quotemstr wrote: post #19

Earlier quoted context omitted.

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

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.

Huh? It doesn't follow that forbidding blocking IO is either necessary or sufficient for concurrency safety, at least under any definition of "safety" I can imagine. What do you mean? You mean async-not-blocking-event-loop stuff? That's not the only way to do more than one IO at a time.

Re: Garbage collection without unsafe code

#26

Post by Arch485 »

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…

I agree completely; I think choosing Rust and then adding a GC is a weird design choice. If I was in a situation where I really, truly needed GC for my memory management, I wouldn't use Rust.

Re: Garbage collection without unsafe code

#27

Post by staticassertion »

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.

> so the domain in which you can beat their performance

Not in my experience.

Re: Garbage collection without unsafe code

#28

Post by pjmlp »

quotemstr wrote: post #17
pjmlp wrote: post #9

Earlier quoted context omitted.

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.

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.

Re: Garbage collection without unsafe code

#29

Post by marcosscriven »

rurban wrote: post #23
marcosscriven wrote: post #20

Earlier quoted context omitted.

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?

Sure, besides those bugs, read the specs. unsafe blocks. Loud and clear. worse than in Java where the unsafeties were just in a hidden sun class.

I was familiar with the concept of unsafe blocks. What I didn’t know was there were issues outside that.

Re: Garbage collection without unsafe code

#30

Post by gignico »

swiftcoder wrote: post #21
pjmlp wrote: post #12

Earlier quoted context omitted.

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.

> Given your nick Weirdly, I picked this screen name about a decade before Swift the language (and several years before Swift the singer) debuted

Too bad HN nicknames cannot be put for sale :)
Post reply on HN