I kinda feel like complaints that using indexing over refs is "bypassing the borrow checker" miss the point. That's like complaining allocation "bypasses the stack".
-
-
My argument is precisely that stepping out of Rust's *default* guarantees is a deliberate feature of the language and not exiting the problem domain. You're right that it's suboptimal that ECS requires this, but I don't think that's the original point.
-
Er, suboptimal that cyclic graph structures require this. ECS systems are array based *anyway*
-
then again, there's a name for "system that automatically manages memory arranged in a cyclic graph structure", and not having one of those is one of rust's big selling points
-
I'm sad we killed Gc<T>, actually.
-
There's scope for both a pure library version (rust-gc exists, it's kinda naïve but safe) and one the compiler helps with via stack maps (I worked on this earlier, but ultimately it was low priority so we never implemented it)
End of conversation
New conversation -
-
-
But you don't want to use pointers / references for any serious ecs system anyway so I'm not sure what the difference is?
-
Right, ECS systems are AOS<->SOA *anyway* the video wasn't about ECS in rust requiring indexing, ECS pretty much always does. The video said that Rust's borrow checker forces you into the ECS corner anyway by making your code require indexing.
End of conversation
New conversation -
-
-
hold up, which meaning of ECS?
-
hi i feel like 'ecs subverts the borrow checker' is misleadng but 'rust's lack of allocator support is not fixed by using an array and passing around offsets'
-
sorry not ecs, vec thing ugh words
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.