Well if you’re calling any form of automatic memory management garbage collection, then it’s only C that doesn’t have garbage collection.
Rust does have explicit reference counting with Rc<T> and Arc<T>.
I’m trying to explain to you that static analysis that limits references to one can be done in a similar way without the limit of one (especially with the assumption of immutability) whilst retaining in-place mutation where the count really is one. It upsets you when I try to explain that it’s a generalisation of the borrow checker (without the programmer pain) by calling the borrow checker a static (compile time) reference counter with a limit of one. I’m making a comparison. But don’t be surprised if a lot of programming languages implement their boolean variables as an unsigned int with a maximum of one.
If roc does the equivalent of putting a call to drop where there were two or three references that fell out of scope rather than one, in what sense is that more overhead than rust calling drop when one reference went out of scope? Rust is still “garbage collecting” the references that turned up on the RHS of assignment statements as it goes along.
The overhead we’re talking about with reference counting is like DEC rBRZ. It’s like array bounds checking. Yes, it’s an overhead, but no, it’s not worth making a big deal about it if you get to allocate arrays of sizes unknown at compile time or you get to make multiple references without messing with keywords and reference symbols, fighting the borrow checker all day long or manually adding clones.
It says some overheads. It’s different overheads,
What? Overheads are overheads. Either they’re small and useful like roc’s reference counting when it turns out to need to be at runtime or array bounds checking, or rust calling drop when some variable falls out of scope, or they’re big, stop the main thread at random points and take a long time, like garbage collection in garbage collected languages like java.
Why say more if it’s ignored anyway?
I know - I wrote a whole bunch of stuff and this other person just ignored every single nuance and explanation and kept saying the same thing again and again without trying to understand a new thing they didn’t know about before, just repeating their favourite criticisms of other programming languages whether they applied or not. Oh wait, that was you.
Well if you’re calling any form of automatic memory management garbage collection, then it’s only C that doesn’t have garbage collection.
Rust does have explicit reference counting with Rc<T> and Arc<T>.
I’m trying to explain to you that static analysis that limits references to one can be done in a similar way without the limit of one (especially with the assumption of immutability) whilst retaining in-place mutation where the count really is one. It upsets you when I try to explain that it’s a generalisation of the borrow checker (without the programmer pain) by calling the borrow checker a static (compile time) reference counter with a limit of one. I’m making a comparison. But don’t be surprised if a lot of programming languages implement their boolean variables as an unsigned int with a maximum of one.
If roc does the equivalent of putting a call to drop where there were two or three references that fell out of scope rather than one, in what sense is that more overhead than rust calling drop when one reference went out of scope? Rust is still “garbage collecting” the references that turned up on the RHS of assignment statements as it goes along.
The overhead we’re talking about with reference counting is like
DEC r
BRZ
. It’s like array bounds checking. Yes, it’s an overhead, but no, it’s not worth making a big deal about it if you get to allocate arrays of sizes unknown at compile time or you get to make multiple references without messing with keywords and reference symbols, fighting the borrow checker all day long or manually adding clones.What? Overheads are overheads. Either they’re small and useful like roc’s reference counting when it turns out to need to be at runtime or array bounds checking, or rust calling drop when some variable falls out of scope, or they’re big, stop the main thread at random points and take a long time, like garbage collection in garbage collected languages like java.
I know - I wrote a whole bunch of stuff and this other person just ignored every single nuance and explanation and kept saying the same thing again and again without trying to understand a new thing they didn’t know about before, just repeating their favourite criticisms of other programming languages whether they applied or not. Oh wait, that was you.
Interesting.