4 ms·

> It's brittle, and full of internal relative addresses within the data item, I am not sure how much you would gain by doing this. Internal references are one

> It's brittle, and full of internal relative addresses within the data item, I am not sure how much you would gain by doing this. Internal references are one of the things where it is very hard to express in safe Rust what you want to do (see doubly linked lists and graphs). You can get around that by using vectors and indexes, but that is bypassing the borrow checker, and with it, much of your safety and mutability checks.

amelius 4y ago
Yes, Rust is great for tree-like data structures. However, add one non-tree edge to your graph and you're in big trouble. This demonstrates the flexibility of GC'd languages, where you don't paint yourself into a corner so easily.
- Animats 4y ago
  Yes, Rust is great for tree-like data structures. However, add one non-tree edge to your graph and you're in big trouble. Good summary. Most of the headaches I have in Rust come from needing something that's not a simple tree. Parts that are simple trees are really easy. Nanite is a DAG, by the way. The whole point of Nanite is that instances are combined, recursively. A mile of chain link fence would be highly detailed sections of wire, combined into full wires, combined into fence panels... But not just all simple repeats. If there's a hole in the fence somewhere, that can be represented.
- stouset 4y ago
  I really don’t get this perspective. People act like you need one self-referential struct and suddenly you’ve gotta switch languages. Just use unsafe! That’s what it’s there for. You can use internally-unsafe semantics to expose an externally-safe API and nobody needs to care. You get the Rust’s safety benefits everywhere else (not to mention all the other nice parts) and your unsafe code is limited only to the areas it’s truly necessary.
  - amelius 4y ago
    You can't always hide the problem behind an API, because for instance an API may call back into your code and access data. Or it may want to do that in the future. The "unsafe" world will spread like a virus.
    - stouset 4y ago
      Absolutely ridiculous. Rust itself is written using plenty of unsafe code, all of which runs on top of fundamentally-unsafe CPU architectures. And yet it manages to expose a safe API to its users who somehow to write memory-safe Rust programs every day. > You can't always hide the problem behind an API, because for instance an API may call back into your code and access data. This is quite literally all that Cell and RefCell do and they hide this behavior behind a safe API. Do memory-safety leaks in supposedly memory-safe abstractions crop up occasionally? Sure, nobody's perfect. But this idea that unsafety is uncontainable and spreads out everywhere until your whole program is infected and riddled with memory-safety bugs is completely detached from reality and regularly disproven by Rust developers on a daily basis.
      - amelius 4y ago
        Rust is still in a research phase. People are still figuring out how to do certain very basic stuff without a garbage collector. See e.g. how long it has been taking to get a decent GUI library with callback functions that can be closures that reference external parts of data. In my view it is silly to do very high-level stuff in a systems language that was never intended for that purpose, and when you can clearly see the downsides of that approach; you are thinking of memory issues a large part of the time instead of being able to focus on your high-level functionality or even high-level security issues. Of course you can try to do it, but then it is research, not practical or necessarily sustainable programming.
        deleted 4y ago
        [deleted]
        4y ago
oconnor663 4y ago
I always want to be careful with phrases like "bypassing safety checks", because of course the Vec/index pattern is 100% safe and (like any 100% safe Rust program) will (approximately) never trigger undefined behavior. But it's true that what was formerly undefined behavior will still be a bug, where a stale index accidentally refers to a new object that happens to get allocated in the same spot. You can use slabs and generational indexes to catch these bugs, but I don't know whether the performance cost of generational indexes is acceptable in this case.
- ChickeNES 4y ago
  > here a stale index accidentally refers to a new object that happens to get allocated in the same spot. Given we're talking video games, you could also not worry and let speedrunners take advantage of it... ;)

amelius 4y ago

Yes, Rust is great for tree-like data structures. However, add one non-tree edge to your graph and you're in big trouble. This demonstrates the flexibility of GC'd languages, where you don't paint yourself into a corner so easily.

Animats 4y ago
Yes, Rust is great for tree-like data structures. However, add one non-tree edge to your graph and you're in big trouble. Good summary. Most of the headaches I have in Rust come from needing something that's not a simple tree. Parts that are simple trees are really easy. Nanite is a DAG, by the way. The whole point of Nanite is that instances are combined, recursively. A mile of chain link fence would be highly detailed sections of wire, combined into full wires, combined into fence panels... But not just all simple repeats. If there's a hole in the fence somewhere, that can be represented.
stouset 4y ago
I really don’t get this perspective. People act like you need one self-referential struct and suddenly you’ve gotta switch languages. Just use unsafe! That’s what it’s there for. You can use internally-unsafe semantics to expose an externally-safe API and nobody needs to care. You get the Rust’s safety benefits everywhere else (not to mention all the other nice parts) and your unsafe code is limited only to the areas it’s truly necessary.
- amelius 4y ago
  You can't always hide the problem behind an API, because for instance an API may call back into your code and access data. Or it may want to do that in the future. The "unsafe" world will spread like a virus.
  - stouset 4y ago
    Absolutely ridiculous. Rust itself is written using plenty of unsafe code, all of which runs on top of fundamentally-unsafe CPU architectures. And yet it manages to expose a safe API to its users who somehow to write memory-safe Rust programs every day. > You can't always hide the problem behind an API, because for instance an API may call back into your code and access data. This is quite literally all that Cell and RefCell do and they hide this behavior behind a safe API. Do memory-safety leaks in supposedly memory-safe abstractions crop up occasionally? Sure, nobody's perfect. But this idea that unsafety is uncontainable and spreads out everywhere until your whole program is infected and riddled with memory-safety bugs is completely detached from reality and regularly disproven by Rust developers on a daily basis.
    - amelius 4y ago
      Rust is still in a research phase. People are still figuring out how to do certain very basic stuff without a garbage collector. See e.g. how long it has been taking to get a decent GUI library with callback functions that can be closures that reference external parts of data. In my view it is silly to do very high-level stuff in a systems language that was never intended for that purpose, and when you can clearly see the downsides of that approach; you are thinking of memory issues a large part of the time instead of being able to focus on your high-level functionality or even high-level security issues. Of course you can try to do it, but then it is research, not practical or necessarily sustainable programming.
      - deleted 4y ago
        [deleted]
      - 4y ago

oconnor663 4y ago

I always want to be careful with phrases like "bypassing safety checks", because of course the Vec/index pattern is 100% safe and (like any 100% safe Rust program) will (approximately) never trigger undefined behavior. But it's true that what was formerly undefined behavior will still be a bug, where a stale index accidentally refers to a new object that happens to get allocated in the same spot. You can use slabs and generational indexes to catch these bugs, but I don't know whether the performance cost of generational indexes is acceptable in this case.

ChickeNES 4y ago
> here a stale index accidentally refers to a new object that happens to get allocated in the same spot. Given we're talking video games, you could also not worry and let speedrunners take advantage of it... ;)