4 ms·

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 i

• pclmulqdq 2y ago
  A game engine is much more similar to a browser engine than you think. The operations you have discussed, using bits as flags, are also the most basic forms of binary-level manipulation out there. Things like tagged pointers and bit flags fit nicely and neatly into an encapsulated unsafe abstraction (provided you want to add an extra 1000 lines of code for it). 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.
  • CryZe 2y ago
    Take a look into bytemuck or zerocopy. I haven't used unsafe when doing byte level manipulation in a long time.
  • Ygg2 2y ago
    And a jet engine and IC engine are engines, but putting your car engine into a Boeing and vice versa would be an unwise decision. 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.
    • pclmulqdq 2y ago
      Browsers need very high performance, too.
      • Ygg2 2y ago
        To be fair to my analogy, both ICE and Jet engines need high RPMs too, and pull power but not on the same level. 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.
        • eru 2y ago
          C was designed to write Unix, but they didn't overfit it for that very specific case only. So it has seen application elsewhere. Neither was Rust overfitted to exactly only writing browser engines.
    • eru 2y ago
      > And a jet engine and IC engine are engines, but putting your car engine into a Boeing and vice versa would be an unwise decision. 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.
  • pcwalton 2y ago
    > 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. No, that's what bytemuck is for. If bytemuck didn't exist, sure, I'd be using a lot of unsafe.
    • pclmulqdq 2y ago
      Bytemuck handles the latter, not the former. In the applications I am working on, both matter.
      • pcwalton 2y ago
        I can't quite parse your statement, but if you mean that bytemuck doesn't let you "rely on the exact binary layout of something in memory", then yes, it does: it lets you cast from a Pod type to another Pod type, which exposes the memory layout of both types.