Garbage collection for Rust: The finalizer frontier • Hacker News Board

Re: Garbage collection for Rust: The finalizer frontier

#11

Post by virgilp » Wed, Oct 15, 2025, 2:57 PM UTC

sebastianconcpt wrote: post #9

jvanderbot wrote: post #7

Earlier quoted context omitted.

While you're of course correct, there's just something that feels off. I'd love if we kept niche, focused-purpose languages once in a while, instead of having every language do everything. If you prioritize everything you prioritize nothing.

> If you prioritize everything you prioritize nothing Well... If you prioritize everything you prioritize generalism. (the "nothing" part comes from our natural limitation to pay enough multidisciplinary attention to details but that psychological impression is being nuked with AI as we speak and the efforts to get to AGI are an attempt to make synthetic "intelligence" be able to gain dominion over this spirit before…

No, they are quite identical. Both cases logically lead to "now everything has the same priority". There's nothing about generalism in there.

Re: Garbage collection for Rust: The finalizer frontier

#12

Post by gizmo686 » Wed, Oct 15, 2025, 3:02 PM UTC

gwbas1c wrote: post #5

Before making criticisms that Garbage Collection "defeats the point" of Rust, it's important to consider that Rust has many other strengths: - Rust has no overhead from a "framework" - Rust programs start up quickly - The rust ecosystem makes it very easy to compile a command-line tool without lots of fluff - The strict nature of the language helps guide the programmer to write bug-free code. In short: There's a lot…

Also, the proposed garbage collector is still opt in. Only pointers that are specifically marked as GC are garbage collected. This means that most references are still cleaned up automatically when the owner goes out of scope. This greatly reduces the cost of GC compared to making all heap allocations garbage collected.

This isn't even a new concept in Rust. Rust already has a well accepted RC type for reference counted pointers. From a usage perspective, GC seems to fit in the same pattern.

Re: Garbage collection for Rust: The finalizer frontier

#13

Post by gwbas1c » Wed, Oct 15, 2025, 3:22 PM UTC

jvanderbot wrote: post #6

gwbas1c wrote: post #5

Before making criticisms that Garbage Collection "defeats the point" of Rust, it's important to consider that Rust has many other strengths: - Rust has no overhead from a "framework" - Rust programs start up quickly - The rust ecosystem makes it very easy to compile a command-line tool without lots of fluff - The strict nature of the language helps guide the programmer to write bug-free code. In short: There's a lot…

You've just listed "Compiled language" features. Only the 4th point has any specificity to Rust, and even then, is vague in a way that could be misinterpreted. Rust's predominant feature, the one that brings most of its safety and runtime guarantees, is borrow checking. There are things I love about Rust besides that, but the safety from borrow checking (and everything the borrow checker makes me do) is why I like pr…

Oh no, I'm directly criticizing C/C++/Java/C#:

The heavyweight framework (and startup cost) that comes with Java and C# makes them challenging for widely-adopted lightweight command-line tools. (Although I love C# as a language, I find the Rust toolchain much simpler and easier to work with than modern dotnet.)

Building C (and C++) is often a nightmare.

Re: Garbage collection for Rust: The finalizer frontier

#14

Post by reactordev » Wed, Oct 15, 2025, 3:23 PM UTC

ape4 wrote: post #4

If only there was a C++-like language with garbage collection (Java, C#, etc)

Latest version of C# is a fantastic choice for this. Java too but I would lean more C# due to the new delegate function pointers for source-generated p/invoke. Thing of beauty.

Re: Garbage collection for Rust: The finalizer frontier

#15

Post by jrop » Wed, Oct 15, 2025, 3:26 PM UTC

jvanderbot wrote: post #6

gwbas1c wrote: post #5

Before making criticisms that Garbage Collection "defeats the point" of Rust, it's important to consider that Rust has many other strengths: - Rust has no overhead from a "framework" - Rust programs start up quickly - The rust ecosystem makes it very easy to compile a command-line tool without lots of fluff - The strict nature of the language helps guide the programmer to write bug-free code. In short: There's a lot…

You've just listed "Compiled language" features. Only the 4th point has any specificity to Rust, and even then, is vague in a way that could be misinterpreted. Rust's predominant feature, the one that brings most of its safety and runtime guarantees, is borrow checking. There are things I love about Rust besides that, but the safety from borrow checking (and everything the borrow checker makes me do) is why I like pr…

Just going to jump in here and say that there's another reason I might want Rust with a Garbage Collector: The language/type-system/LSP is really nice to work with. There have indeed been times that I really miss having enums + traits, but DON'T miss the borrow checker.

Re: Garbage collection for Rust: The finalizer frontier

#16

Post by hypeatei » Wed, Oct 15, 2025, 3:28 PM UTC

gwbas1c wrote: post #13

jvanderbot wrote: post #6

Earlier quoted context omitted.

You've just listed "Compiled language" features. Only the 4th point has any specificity to Rust, and even then, is vague in a way that could be misinterpreted. Rust's predominant feature, the one that brings most of its safety and runtime guarantees, is borrow checking. There are things I love about Rust besides that, but the safety from borrow checking (and everything the borrow checker makes me do) is why I like pr…

Oh no, I'm directly criticizing C/C++/Java/C#: The heavyweight framework (and startup cost) that comes with Java and C# makes them challenging for widely-adopted lightweight command-line tools. (Although I love C# as a language, I find the Rust toolchain much simpler and easier to work with than modern dotnet.) Building C (and C++) is often a nightmare.

> The heavyweight framework

Do you mean the VM/runtime? If so, you might be able to eliminate that with an AOT build.

> I find the Rust toolchain much simpler and easier to work with than modern dotnet

What part of the toolchain? I find them pretty similar with the only difference being the way you install them (with dotnet coming from a distro package and Rust from rustup)

Re: Garbage collection for Rust: The finalizer frontier

#17

Post by torginus » Wed, Oct 15, 2025, 3:29 PM UTC

While I'm not ideologically opposed to GC in Rust I have to note:

- the syntax is hella ugly

- GC needs some compiler machinery, like precise GC root tracking with stack maps, space for tracking visted objects, type infos, read/write barriers etc. I don't know how would you retrofit this into Rust without doing heavy duty brain surgery on the compiler. You can do conservative GC without that, but that's kinda lame.

Re: Garbage collection for Rust: The finalizer frontier

#18

Post by tayo42 » Wed, Oct 15, 2025, 3:43 PM UTC

jvanderbot wrote: post #6

gwbas1c wrote: post #5

Before making criticisms that Garbage Collection "defeats the point" of Rust, it's important to consider that Rust has many other strengths: - Rust has no overhead from a "framework" - Rust programs start up quickly - The rust ecosystem makes it very easy to compile a command-line tool without lots of fluff - The strict nature of the language helps guide the programmer to write bug-free code. In short: There's a lot…

You've just listed "Compiled language" features. Only the 4th point has any specificity to Rust, and even then, is vague in a way that could be misinterpreted. Rust's predominant feature, the one that brings most of its safety and runtime guarantees, is borrow checking. There are things I love about Rust besides that, but the safety from borrow checking (and everything the borrow checker makes me do) is why I like pr…

What other language has modern features like rust and is compiled?

Re: Garbage collection for Rust: The finalizer frontier

#19

Post by IainIreland » Wed, Oct 15, 2025, 3:46 PM UTC

king_terry wrote: post #2

The whole point of Rust is to not have a garbage collector while not worrying about memory leaks, though.

One clear use case for GC in Rust is for implementing other languages (eg writing a JS engine). When people ask why SpiderMonkey hasn't been rewritten in Rust, one of the main technical blockers I generally bring up is that safe, ergonomic, performant GC in Rust still appears to be a major research project. ("It would be a whole lot of work" is another, less technical problem.)

For a variety of reasons I don't think this particular approach is a good fit for a JS engine, but it's still very good to see people chipping away at the design space.

Re: Garbage collection for Rust: The finalizer frontier

#20

Post by tuveson » Wed, Oct 15, 2025, 3:47 PM UTC

jrop wrote: post #15

jvanderbot wrote: post #6

Earlier quoted context omitted.

You've just listed "Compiled language" features. Only the 4th point has any specificity to Rust, and even then, is vague in a way that could be misinterpreted. Rust's predominant feature, the one that brings most of its safety and runtime guarantees, is borrow checking. There are things I love about Rust besides that, but the safety from borrow checking (and everything the borrow checker makes me do) is why I like pr…

Just going to jump in here and say that there's another reason I might want Rust with a Garbage Collector: The language/type-system/LSP is really nice to work with. There have indeed been times that I really miss having enums + traits, but DON'T miss the borrow checker.

Maybe try a different ML-influenced language like OCaml or Scala. The main innovation of Rust is bringing a nice ML-style type system to a more low level language.