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

Garbage collection for Rust: The finalizer frontier

soft-dev.org

Post reply on HN
Print view View original

31–40 of 184 posts

Re: Garbage collection for Rust: The finalizer frontier

#31

Post by dzaima »

hedora wrote: post #27
king_terry wrote: post #2

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

Yeah; I wished they'd gone the other way, and made memory leaks unsafe (yes, this means no Rc or Arc). That way, you could pass references across async boundaries without causing the borrow checker to spuriously error out. (It's safe to leak a promise, so there's no way for the borrow checker to prove an async function actually returned before control flow is handed back to the caller.)

Same as with GC, neither need be a fixed choice; having a GC library/feature in Rust wouldn't mean that everything will be and must be GC'd; and it's still possible to add unleakable types were it desired: https://rust-lang.github.io/keyword-generics-initiative/eval... while keeping neat things like Rc available for things that don't care. (things get more messy when considering defaults and composability with existing libraries, but I'd say that such issues shouldn't prevent the existence of the options themselves)

Re: Garbage collection for Rust: The finalizer frontier

#32

Post by kbolino »

procaryote wrote: post #25
gwbas1c wrote: post #13

Earlier quoted context omitted.

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.

Hello world in java is pretty fast. Not rust fast but a lot faster than you'd expect. Java starting slowly is mostly from all the cruft in the typical java app, with springboot, dependency injection frameworks, registries etc. You don't have to have those, it's just that most java devs use them and can't conceive of a world of low dependencies Still not great for commandline apps, but java itself is much better than…

Java's biggest weakness in this area is its lack of value types. It's well known, Project Valhalla has been trying to fix it for years, but the JVM just wasn't built around such types and it's hard to bolt them on after the fact. Java's next biggest weakness (which will become more evident with value types) is its type-erased generics. Both of these problems lead to time wasted on unnecessary GC, and though they can be worked around with arrays and codegen, it's unwieldy to say the least.

Re: Garbage collection for Rust: The finalizer frontier

#33

Post by rixed »

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…

In all honesty, there are three topics I try to refrain myself from engaging with on HN, often unsuccesfully: politics, religion, and rust.

I don't know what you had to go through before reaching rust's secure haven, but what you just said is true for the vast majority of compiled languages, which are legions.

Re: Garbage collection for Rust: The finalizer frontier

#34

Post by Manishearth »

king_terry wrote: post #2

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

Worth highlighting: library-level GC would not be convenient enough to use pervasively in Rust anyway. library-level GC does not replace Rust's "point".

It's useful to have when you have complex graph structures. Or when implementing language runtimes. I've written a bit about these types of use cases in https://manishearth.github.io/blog/2021/04/05/a-tour-of-safe...

And there's a huge benefit in being able to narrowly use a GC. GCs can be useful in gamedev, but it's a terrible tradeoff to need to use a GC'd language to get them, because then everything is GCd. library-level GC lets you GC the handful of things that need to be GCd, while the bulk of your program uses normal, efficient memory management.

Re: Garbage collection for Rust: The finalizer frontier

#35

Post by James_K »

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…

Go is probably a better pick in this case.

Re: Garbage collection for Rust: The finalizer frontier

#36

Post by James_K »

king_terry wrote: post #2

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

Actually, memory leaks are the major class of memory error for which Rust offers no protection. See the following safe function in Box:

https://doc.rust-lang.org/std/boxed/struct.Box.html#method.l...

Re: Garbage collection for Rust: The finalizer frontier

#37

Post by ltratt »

nu11ptr wrote: post #29

While it might be useful for exploration/academic pursuit/etc., am I the only one who finds "conservative GC" a non-starter? Even if this was fully production ready, I had a use case for it, etc. I still would never ship an app with a conservative GC. It is difficult enough to remove my own bugs and non-determinism, and I just can't imagine trying to debug a memory leak caused due to a conservative GC not finding all…

If you've used Chrome or Safari to read this post, you've used a program that uses (at least in parts) conservative GC. [I don't know if Firefox uses conservative GC; it wouldn't surprise me if it does.] This partly reflects shortcomings in our current compilers and in current programming language design: even Rust has some decisions (e.g. pointers can be put in `usize`s) that make it hard to do what would seem at first glance to be the right thing.

Re: Garbage collection for Rust: The finalizer frontier

#38

Post by ComputerGuru »

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.

New AOT C# is nice, but not fully doable with the most common dependencies. It addresses a lot of the old issues (size, bloat, startup latency, etc)

Re: Garbage collection for Rust: The finalizer frontier

#39

Post by gizmo686 »

procaryote wrote: post #25
gwbas1c wrote: post #13

Earlier quoted context omitted.

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.

Hello world in java is pretty fast. Not rust fast but a lot faster than you'd expect. Java starting slowly is mostly from all the cruft in the typical java app, with springboot, dependency injection frameworks, registries etc. You don't have to have those, it's just that most java devs use them and can't conceive of a world of low dependencies Still not great for commandline apps, but java itself is much better than…

Testing on my machine, Hello World in java (openjdk 21) takes about 30ms.

In contrast, "time" reports that rust takes 1ms, which is the limit of it's precision.

Python does Hello World in just 8ms, despite not having a separate AOT compilation step.

The general guidance I've seen for interaction is that things start to feel laggy at 100ms; so 30ms isn't a dealbreaker, but throwing a third of your time budget at the baseline runtime cost is a pretty steep ask.

If you want to use the application as a short lived component in a larger system, than 30ms on every invocation can be a massive cost.

Re: Garbage collection for Rust: The finalizer frontier

#40

Post by tayo42 »

procaryote wrote: post #28
tayo42 wrote: post #18

Earlier quoted context omitted.

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

it depends completely on what you put in "modern features"

Pattern matching, usable abstractions, non null types, tagged unions or w/e enums are, build tools etc
Post reply on HN