Fundamentally, Bevy prioritizes different things than many of its competitors, and is actively experimenting in all of its domains.

Some of the larger distinctions:

- Everything lives in the ECS

- The ECS is incredibly ergonomic: basically just structs and functions

- Systems are automatically run in parallel based on their type signatures

- Rendering is powered by a composable rendering graph

- Everything is modular, and engine code looks like user code

- A culture that cares about genuinely good, up to date docs

As we grow to properly cover more areas, this list will grow. I'm one of the core contributors to Bevy and I can assure you we're not interested in writing "yet another game engine" <3

Your reply was insightful until i read the last part:

> As we grow to properly cover more areas, this list will grow. I'm one of the core contributors to Bevy and I can assure you we're not interested in writing "yet another game engine" <3

Rust people gotta be Rust people, that's sad

The type system of Rust requires you to be clear about which data your code is touching, and whether that code can mutate it or is just reading. This allows a sufficiently smart task system—like that of Bevy—to automatically distribute work across threads for better hardware utilization.

Also, one of the main reasons I'm interested in Bevy is that the engine is modular, pluggable, and extensible at the core renderer level, which is nice for those of us experimenting with different rendering techniques. Unity in particular is not a good fit for this type of thing.

From what I gathered the ECS (Entity Component System) it uses allows for great performance.

This aside: if we assume the speed gains in future computing will be more about number of cores than CPU frequency then using a language which has some guarantees around concurrent code and data races is probably not a bad idea. It is really quite easy to shoot yourself into the foot when you run parallel code in traditional systems programming languages.

The issues hobbyist game developers face don't typically have anything to do with performance, though. The issues they face are that no one plays their games, sometimes because they're too simple, and the software toolchain they're using isn't powerful enough to help them.

I definitely agree that performance is really not the thing that hobbyist game developers need. However, hobbyist game devs aren't (our only) target market.

Right now, the team who is seeing the most success with Bevy are actually building CAD software! They needed something powerful, fast, incredibly flexible with "game-like" functionality.

That said, from talking to the hobbyists in the community, they like Bevy because it's:

- code-first

- written in Rust (C# is fine, but Unity's C# is something of a DSL, and game engine C++ is really rough)

- cares about good documentation and a helpful learning experience

- supports them in contributing fixes to issues they run into

- is incredibly flexible: you can just swap in your own physics or rendering to realize that weird idea you had, or just for the learning experience

Who says this is targeted at hobbyist game developers?

Someone liked the idea of writing a game engine in Rust and so they did. I wrote my own sidescroller engine when I was 16 as well, although there were existing things around and it thought me a great deal about how to tackle multiple classes of problems.

Now the bevy devs seem way more experienced and if there was already a game engine that ticked all their boxes they might not have started developing a new one. But the point here is: Not everything is a product with an clearcut target audience — and not everything has to be.

Projects like these ultimately help the whole field of game engines to move on and innovate.

Most non-commercial game software is. I think it's meaningful to note that, because it helps clarify the authors' intentions.

Also, the gaming industry has shifted such that performance is important. Go on any gaming forum and assert 30fps and 60fps are equivalent, or a 60fps that's not stable is OK.

Unity in particular was a meme for the last generation due to CPU-based stuttering.

Is the ECS paradigm useful in enterprise situations e.g. database driven (web)applications?

Most ECS implementations realistically are high-performance in-memory columnar databases, where systems use granular mutation patterns. Hell, the main access pattern is literally a called a Query. It's become quite a meme to call bevy_ecs "turning games into SQL databases". If you've used BigQuery or Redshift, you've basically just used a super-scaled up ECS engine.

I think to some extent that's still an open question that hasn't been fully explored. I've seen a lot of people suggesting it could work well for application UI development, but nobody has proved it out with a solid implementation yet.

why don't you click the link and find out?