On one hand, its just a shortcut to moving a value into the transparent ManuallyDrop struct and forgetting the result. In most cases, ManuallyDrop is the preferred way, as it allows encoding this behaviour (disabling the built-in drop) on a type level.
And if you want arenas or similar structures, they simply don't need to use either. The arena struct itself usually implements Drop to enact whatever it needs for deallocating the data its storing. The things stored in them also don't need ManuallyDrop since they're just written to memory directly using unsafe calls, and the compiler doesn't know this data exists (depending on implementation, some directly use syscalls, others use a Rust datastructure like Vec<u8> for allocating their memory). Nowhere in this is mem::forget or ManuallyDrop required, and the resulting API is usually far nicer than dealing with ManuallyDrop.
It does in a way use a limited subset. Specifically, the borrow checker is rarely a concern since Bevys ECS storage abstracts that mostly away from the user.
Edit: i was a dunce and explained data-driven, which it also is, but is not what you asked.
Bevy is data oriented due to its ECS: roughly: which data an entity has attached to it decides which behaviours are run. Want something to have a health bar? Just attach the Health { current: 50, max: 100 } struct and it will have all associated behaviour like being able to take damage. Want to make it invincible again? Just remove the Health struct.
This is different from OOP engines, where you might need to keep an is_invincible boolean around to check against.
There was a user on discord a while back who got bevy running in some capacity on, I think, Xbox and Switch. He had trouble with the PlayStation, though. Since you have to sign NDAs with the companies to do that, I don't know what came of it.
We're certainly not denying that the work is significant and valuable! From an HN point of view, the only question is whether the submissions are different enough to support substantially different discussions in the thread.
On one hand, its just a shortcut to moving a value into the transparent ManuallyDrop struct and forgetting the result. In most cases, ManuallyDrop is the preferred way, as it allows encoding this behaviour (disabling the built-in drop) on a type level.
And if you want arenas or similar structures, they simply don't need to use either. The arena struct itself usually implements Drop to enact whatever it needs for deallocating the data its storing. The things stored in them also don't need ManuallyDrop since they're just written to memory directly using unsafe calls, and the compiler doesn't know this data exists (depending on implementation, some directly use syscalls, others use a Rust datastructure like Vec<u8> for allocating their memory). Nowhere in this is mem::forget or ManuallyDrop required, and the resulting API is usually far nicer than dealing with ManuallyDrop.