It's not. It's Bevy.
What effects this is separating your unsafe into unsafe abstractions. If you're careful you don't have to write too much unsafe. Granted it's not easy.
What effects this is separating your unsafe into unsafe abstractions. If you're careful you don't have to write too much unsafe. Granted it's not easy.
As far as I can tell, any time you want to rely on the exact binary layout of something in memory, you need unsafe. As a corollary, any time you want to bit cast from one type to another, you need unsafe. This means that things like succinct data structures and building network protocols need quite a bit of unsafe everywhere. The former needs you to do things like "store 14 bits of X here and 12 bits there..." The latter needs control of bit and byte layout because you want to carefully eliminate implementation-defined compiler behavior.
I'd argue you're over-abstracting the differences. They have different purposes. Game engines need high performance, while browsers need to enable wide selection of APIs.
Browsers layout and rendering will have some elements similar to that of a game, but it isn't on the same level. A game can usually assume that it's trusted to run that shader, in a browser that's a vector for attack. Security design will impact game engines and browsers differently.
Granted, people are doing their darnedest to make games in the lowest common denominator technology, i.e. Electron.
Neither was Rust overfitted to exactly only writing browser engines.
Sure, but you'd expect the design software for a car engine to be at least half-way relevant for a jet engine in a pinch.
Compared to eg the software an architect would use to design a bridge.
No, that's what bytemuck is for. If bytemuck didn't exist, sure, I'd be using a lot of unsafe.