Hi! I'm one of the four formal maintainers of Bevy. I'm not particularly interested in convincing you personally, but I think it's important to publicly address some misunderstandings.
The scheduling rework that you're complaining about is extremely high priority, and I have personally invested hundreds of hours into redesigning and refactoring this mess (which is now in its third serious iteration). It's a challenging problem, and the volunteer who has taken responsibility for the rewrite has needed to step back for a while as they transition to a new job.
I have also personally invested hundreds of hours writing, editing and reviewing docs for Bevy. That's what got me involved in the first place, and the team has done a great job. A fully revised book is also in the works, but getting the subtle details right are critical.
As for serious projects: I've spoken with about a half-dozen commercial teams, including one with a team size of about 10 and a lifespan of nearly two years. Their feedback is remarkably positive given the immaturity of Bevy and the supporting ecosystem. While there are missing features that they want (hi bevy_ui), and annoying papercuts (yep, those scheduling concerns sure are annoying), they've over all been wildly impressed been how easy to maintain, reliable and performant Bevy has been for them.
> The scheduling rework that you're complaining about is extremely high priority
I see.
> I have also personally invested hundreds of hours writing, editing and reviewing docs for Bevy
Do you refer to the API docs and/or examples, or something else? I think it's important to have updated and more or less extensive API documentation, but it's not a proper resource for people to learn. AFAIK the only other semi-official learning resource is the cheat book, which is fundamental, but also incomplete.
> As for serious projects: I've spoken with about a half-dozen commercial teams [...] they've over all been wildly impressed been how easy to maintain, reliable and performant Bevy has been for them.
I don't have this clear. Are 5/6 teams actually building commercial games with Bevy, or they just planning to do it in the future? This is a crucial distinction.
Strongly agreed on the need for better introductory material; the existing book is extremely incomplete.
> I don't have this clear. Are 5/6 teams actually building commercial games with Bevy, or they just planning to do it in the future? This is a crucial distinction.
I know of 2 released commercial projects, the CAD team, a few indie devs who have started and 3 or so small studios who are looking to start. There's a little thread in the Discord where I've rounded folks up: [Bevy in production](https://discord.com/channels/691052431525675048/995713618526...).
The scheduling rework that you're complaining about is extremely high priority, and I have personally invested hundreds of hours into redesigning and refactoring this mess (which is now in its third serious iteration). It's a challenging problem, and the volunteer who has taken responsibility for the rewrite has needed to step back for a while as they transition to a new job.
I have also personally invested hundreds of hours writing, editing and reviewing docs for Bevy. That's what got me involved in the first place, and the team has done a great job. A fully revised book is also in the works, but getting the subtle details right are critical.
As for serious projects: I've spoken with about a half-dozen commercial teams, including one with a team size of about 10 and a lifespan of nearly two years. Their feedback is remarkably positive given the immaturity of Bevy and the supporting ecosystem. While there are missing features that they want (hi bevy_ui), and annoying papercuts (yep, those scheduling concerns sure are annoying), they've over all been wildly impressed been how easy to maintain, reliable and performant Bevy has been for them.