Ardour is top tier software. I've been _so_ excited for the "Cue Recording" feature. Until now I've had to resort to other software for live looping. Can't wait to give it a shot / use Ardour for "everything"!
I personally love working with Rust. I think it delivers on the various buzzwords that made it popular. In general when people critique Rust in this context, it comes down to:
1. Rust's ownership / mutability features
Bevy ECS specifically alleviates a lot of the ownership problems that newbies often encounter in Rust. It doesn't solve _all_ of those problems ... there are definitely still UX rough edges. This _will_ be a sticking point for some people. The cost / benefit here is also hard for newbies to evaluate, as it is a _very complicated problem that requires years of experience in the space_.
From my perspective, the cost is worth it. Strict mutability and ownership rules allow us to parallelize everything safely and automatically. Strict mutability allows us to (via the DerefMut trait) _perfectly and automatically_ detect all changes to components and allow developers to react to them. This is something that is unique to Rust, at least in the mainstream. You will not find this type of feature in ECS-es written in other languages, as they literally don't have the semantics to globally distinguish between a read vs write pointer deref.
Opt-in garbage collected ECS is something that people are experimenting with in Rust right now), which would allow people to define "do whatever you want" code.
And _right now_ you can always just use Bevy ECS's unsafe api variants to do whatever you want when the "safety" isn't worth it to you.
I value what I like to call "progressive disclosure of complexity". I want people to be able to quickly and easily use the tools I build without much experience. And as they gain experience, I want them to be able to seamlessly dive further down the stack. I believe Rust handles the encoding the "low level" stuff better than every other language, both by more accurately modeling system constraints and by protecting people from doing the "wrong thing". It also allows you to use those low level pieces to "climb up" the stack until you have something like the Bevy API.
Unlike most engines, in Bevy you can start "at the top" in your program, hit F12 in your IDE to "go to definition", and keep going until you hit the core language APIs. And _then_ you can hit F12 one more time and go into Rust's source code. This experience is extremely empowering, coming from engines like Godot, which have a "high level" API with a "hard cut" before you go into the engine with a completely different language and paradigm (and no good way for your IDE to bridge the gap).
Bevy (and Rust) are for the developers that care about understanding (and controlling) their tools from top to bottom, and are willing to undergo a bit of initial pain (relative to scripting languages) to make that happen. Rust is not a perfect language and it isn't the best "constraint solve" for everyone. But I am most interested in building a holistic experience that empowers people that value that kind of thing.
3. Compile times
Rust compile times can be long if you aren't intentional about it. That being said, Bevy is built in a way to make compile times reasonable. With our "fast compiles" setup (see the getting started guide on our website), I can compile a change to our examples in ~0.5 seconds. Thats close enough to "instant" for me. The trick in general is (1) make sure you aren't writing code in a such a way that requires recompiling EVERYTHING (2) use dynamic linking for large deps (we do this for you in Bevy via the dynamic_linking cargo feature) (3) use a fast linker (covered in our guide).
Ensuring you follow principle (1) in large projects is a skill that needs to be honed. But on the Bevy side, via our opinionated Plugin structure (and dynamically linking those plugins), I think we can provide bounds that discourage people from shooting themselves in the foot.
I will close by saying that it is worth thinking critically about what tools you use and not following hype trains blindly. Picking Rust _and/or_ Bevy for your project _is_ currently something that many people should not do. However I think that Rust and Bevy are both VERY good tools that will be right for some people. And due to their "carefully and seamlessly climb up the stack" approach instead of "riskily climbing down when necessary", they have extremely solid foundations, and their user experience improves constantly. They are both increasingly suitable tools for more and more categories of people, and I expect that trend to continue.
Practically at the moment you do need to learn Rust to use the engine. Our public APIs are all Rust APIs. I'll note that Bevy's ECS makes a lot of Rust more approachable, as it is written to "feel" high level, and it solves a lot of the ownership problems for you that normally trip up newbies. I am of the opinion that Rust is a productive gamedev language, especially in the context of Bevy.
That being said, we've built Bevy ECS and our Bevy Reflect (our Rust reflection library) in a way that enable bindings to other languages to be built. People have built partial Lua and Javascript scripting support on top already. For ecosystem health reasons, I believe that Bevy should have one official language (Rust), but we still want to give people the tools they need to build the integrations they want.
We do get a healthy amount of donations, both from corporations and individuals (see https://bevyengine.org/donate). If you navigate from there to our foundation page, you can see how we spend it. We are a 501c3 non-profit, so each year we MUST file a public annual report as well outlining our activities.
We'd like to land initial BSN features within the next two cycles (obviously sooner is better than later).
We do have plans to upstream a physics plugin, but we aren't yet in a rush to do so, given how great the 3rd party options are. Once visual Bevy Editor workflows start being viable, the pressure to bless a physics plugin will go up I think.
Yup! I've had 95% of the new design written out for weeks now. The last unresolved questions revolved around some scene inheritance details, which I've largely sorted. I've been distracted by release prep, but now that its out I should have this ready in short order. I'll note that the primary focus is rolling out the new scene system / format. This enables and improves UI use cases, but the reactivity bits are still being investigated (ex: check out the bevy_quill and bevy_reactor experiments).
This is _not_ a repost from our perspective. This is a massive new chunk of features and content (993 pull requests from 256 contributors) including new hot-topic features like Virtual Geometry.
Noteworthy: this was our first release that used our new Release Candidate (RC) process and automation to facilitate collaboration on the release blog post. Both of which were a great success! The quality bar of the release has been raised significantly: expect fewer bugs and faster 3rd party plugin updates!
It has certainly been a wild ride. Running an organization is certainly a different skill set. I've learned that I'm pretty good at that side too, but it drains me in a way that programming does not. Bevy's success has definitely been a mixed bag for me. It has been extremely fulfilling and a dream come true. But things were also much simpler, calmer, and pleasant when I was building Bevy alone incognito.
Core pillars (including WIP things like Scene, UI, Editor, Audio) are in place. Partial or full engine stability (see my "partial stabilization discussion: https://github.com/bevyengine/bevy/discussions/9789). More than a few fully released quality games. More than a few fully released quality non-games / tools (we're already seeing Bevy being used as a foundation for things like CAD software and modeling tools).
I recommend checking out Bevy Jam games (which are pretty much always open source) for more complete / real world examples: https://itch.io/jam/bevy-jam-4
Definitely a bit of a gap in our official learning material. Hopefully we can close it soon!
I would say that the systems in the ECS _are_ the game loop. The ECS overhead per frame is kind of hard to measure / it depends on the scale of usage. To establish the scale of operations: Random single-entity ECS data accesses are a sparse array lookup to find the table the entity is in, and then an array lookup to find the component in the table. Iterating components in a query is roughly the same as iterating an array / is very cache friendly. Running individual systems is _slightly_ more expensive than a function call. Scheduling systems in parallel does introduce some overhead (which is currently higher than we'd like / we're working on optimizing it), but when you pay that cost you get the benefits of everything running in parallel.