How compatible can Rust and Godot currently be with commercial products? I don't want to face CPU's memory management garbage collection
ty
How compatible can Rust and Godot currently be with commercial products? I don't want to face CPU's memory management garbage collection
ty
That's not entirely correct. Structures like Rc and Arc exhibit properties of garbage collection.
That's misleading. While the borrow checker checks references during compile time, you can of course have runtime memory management in Rust. E.g. anything that's heap allocated is handled by an Allocator in Rust at runtime.
I think it's quite fair to colloquially use "garbage collection" to refer to a tracing garbage collector, particularly one that applies to nearly all allocations you make in the language.
Reference counting doesn't have the overwhelming majority of the concerning performance issues of a tracing collector, since you only pay for traversing the graph when the objects are actually getting deallocated, rather than near continuously over all objects as memory pressure gets critical (which ideally it is in a game to be making the most use of your hardware!)
But in any case, a game should ideally be avoiding Rc/Arc for the reason of it being a much worse use of the cache. A simple Vec and indices will nearly always win in terms of performance, and it makes the borrow checker a lot easier to deal with too, but means you need to do a lot more bookkeeping yourself.
Eventually that becomes an ECS, but I'm not sure how well that sort of design integrates into Godot - they tend to want to "own the world" (literally!) so it might not match the API.
I will always claim that Rust does not have a garbage collector. Because:
There is no task, separate from your program code, of garbage collection that runs around in the background looking for memory that is no longer used that it can free up.
The time at which memory is actually freed up is entirely determined by the program you have written, your Rust source, not at some random time later when some GC task finds something it can free and actually decides to free it.
Those properties of the likes of Rc and Arc that exhibit properties of GC you mention are something implemented in Rust in your program. They are not hidden under the hood of the Rust language itself. Or built into Rust itself.
It's perfectly possible to write Rust programs that do not depend on the likes of Rc or Arc.
All in al l find claims that Rust has a garbage collector as odd as claiming that local variables on the stack disappearing when a function returns is a form of garbage collection. It really is stretching what "Garbage Collector" has meant for many decades.
Saying "Rust doesn’t have garbage collection at all." does not equal saying "Rust does not have a garbage collector."
Saying "Structures like Rc and Arc exhibit properties of garbage collection." does not equal saying "Rust has a garbage collector.".
None of your four points refer to anything I have written here.
You can claim whatever you want. I really don't care if it's unrelated to what's being discussed.
Well, yeah, it all boils down to how one defines "garbage collector".
As far as I can tell before Rust came along the usage of the term "garbage collector" was pretty cut and dried. Languages like JS and Python etc had garbage collectors and indeed depend on them. Languages like Pascal, C etc did not.
For some reason the definition of "garbage collector" has become blurred when speaking of Rust.
I even dispute that Rust ever even has any "garbage". Objects get dropped the moment they are no longer usable. Either when a local pops off the stack on function return or when some reference count hits zero. Poof! they are freed immediately. There is no garbage hanging around to be collected. So there is no garbage collector.
We just have to agree to disagree. That's OK.
The history might help here, TLDR: LISP introduced tracing GC in 1959 and already internally used the term "garbage collection" but it was immediately followed up with a suggestion to use "reference counting" as a cheaper alternative (though surely the practice existed earlier)
And thus the eternal battle between light and dark began ![]()