3 ms·

I think the point is that if you're juggling integers open you up to the huge correctness messes from before, even if theoretically you've gotten rid of your me

by rtpg 8y ago

I think the point is that if you're juggling integers open you up to the huge correctness messes from before, even if theoretically you've gotten rid of your memory mess. Granted, you could `Option`-up all your operations, but the dynamic GC languages (or even C++) will let you operate on stuff "correctly", so long as your implementation is right. You can go `unsafe` and implement correct stuff and still be better than C++. I really feel like reference IDs aren't a great way to solve something like a doubly-linked list. Reference IDs make you lose almost all guarantees of correctness, unsafe + a good API will at least give you a fighting chance. There are problems (like entity system stuff) where reference IDs are just the way to go, though

kibwen 8y ago
> I think the point is that if you're juggling integers But I don't think anyone should be juggling integers themselves; they should be using a library (just like a library-defined smart pointer) that handles that (the presentation at https://www.youtube.com/watch?v=P9u8x13W7UE https://www.youtube.com/watch?v=P9u8x13W7UE may be of interest). > There are problems (like entity system stuff) where reference IDs are just the way to go, though Sure, and there isn't anything stopping anyone from both using them where they're practical and not using them where they're not. Some of the comments in this thread seem to be suggesting that you must choose one or the other, but that's simply not the case; using references in one part of one's program and indices in another is totally fine, as is using references and indices together in the same part of the program. They're not exclusive. In particular, nobody is saying that one should be reaching for indices regularly; I've written Rust for years and have never, ever needed them. References work just fine for plenty of applications. But we have other smart pointers for good reasons, and sometimes an application will call for the use one of those smart pointers, and that's totally cool; again, references may be thoroughly useful, but they are not the end-all be-all of pointer-like abstractions.
- wbl 8y ago
  Some of us have to write those libraries.
  - AstralStorm 8y ago
    And the GCs too, so that they actually do not cause performance problems (e.g. unpredictable latencies) and help with debugging them instead of getting in the way.

by rtpg 8y ago

kibwen 8y ago

> I think the point is that if you're juggling integers But I don't think anyone should be juggling integers themselves; they should be using a library (just like a library-defined smart pointer) that handles that (the presentation at https://www.youtube.com/watch?v=P9u8x13W7UE https://www.youtube.com/watch?v=P9u8x13W7UE may be of interest). > There are problems (like entity system stuff) where reference IDs are just the way to go, though Sure, and there isn't anything stopping anyone from both using them where they're practical and not using them where they're not. Some of the comments in this thread seem to be suggesting that you must choose one or the other, but that's simply not the case; using references in one part of one's program and indices in another is totally fine, as is using references and indices together in the same part of the program. They're not exclusive. In particular, nobody is saying that one should be reaching for indices regularly; I've written Rust for years and have never, ever needed them. References work just fine for plenty of applications. But we have other smart pointers for good reasons, and sometimes an application will call for the use one of those smart pointers, and that's totally cool; again, references may be thoroughly useful, but they are not the end-all be-all of pointer-like abstractions.

wbl 8y ago
Some of us have to write those libraries.
- AstralStorm 8y ago
  And the GCs too, so that they actually do not cause performance problems (e.g. unpredictable latencies) and help with debugging them instead of getting in the way.