3 ms·
> If we do, the compiler can just make instances disappear statically when we're done with them -- not dynamically! Not possible generally. It would be easy to
by tempguy9999 7y ago
> If we do, the compiler can just make instances disappear statically when we're done with them -- not dynamically!
Not possible generally. It would be easy to create a situation where some kind of refcount is a necessary final fallback.
> The truth is with most of the Rust I write, I don't have to worry about allocation and deallocation of objects, and it happens.
If Rust is the answer, why are you pushing for new langs when Rust is sufficient? Something doesn't add up here.
> Long live the rocket powered horse!
Your response to someone giving their years of experience is that? Well, we're all convinced now.
- ascar 7y ago> If Rust is the answer, why are you pushing for new langs when Rust is sufficient? Something doesn't add up here. Maybe because he said, twice, that Rust is not all the way there?
- tempguy9999 7y agoYou're quite right, thank you, upvoted. However if he says "Rust gets us 80% of the way there" as you point out then he is obliged, IMO, to point out explicitly the 20% where it fails or we can't even begin to discuss it.
- DevoidSimo 7y agoHe mentions Rc and Arc which I assume is what he means by the 20%. I tend to agree, although I'm not sure how you would get rid of them.
- eru 7y ago>> If we do, the compiler can just make instances disappear statically when we're done with them -- not dynamically! > Not possible generally. It would be easy to create a situation where some kind of refcount is a necessary final fallback. Either refcount or a GC. But those situations might be rare in practice with a good system. If you think about it, generational garbage collection implements lots of those heuristics. (But it's closer to a JIT optimizer, not a static optimizer.)