[schreiaj]

Your ECS API looks very similar to that of Bevy's, were you inspired at all by that?

From the little I can see of it, it looks like you don't allow writes to data and instead prefer to return a new thing based on a query? Based entirely on the below.

``` @system def control( sensor: Query[WorldPos, WorldVel, Goal], rw: Query[RWAxis, RWForce] ) -> Query[RWForce]: ```

I assume this is due to the distributed nature of your simulation framework?

Either way, neat. Very interested in this though for more terrestrial applications.

[sphw]

Yeah we are huge fans of Bevy, and heavily inspired by their API. Mutability is tricky in XLA / JAX's computation model. Its optimizations rely on a purely functional style of programming, and so we've tried to map that onto an ECS. In addition, there are some counterintuitive things about programming with JAX that try and discourage through our API. Like accidentally unrolling a loop by using `for` instead of `vmap`.

EDIT: One thing I forgot to add is that we actually use Bevy for our 3D viewer. IMO, its the perfect framework for developing 3d applications that aren't quite games. Most games engines make you carry around a ton of features you will never use, but Bevy is really good at being flexible, lightweight, and easy to use

[schreiaj]

No, I actually like that approach better than the traditional ECS approach. Though I assume it both adds and removes some complexity. In a traditional ECS approach you can depend on certain systems running in certain orders because you depend on them having run. Then you refactor, forget this dependency, and suddenly you have changed behaviors and you have no idea why until you remember this. If, as I assume, you have per step immutability that removes a whole class of bugs at the cost of a slight increase in complexity.