I would argue that even if Bevy was ready for production it would not really compete with Godot.
Godot's performance is plenty for the vast majority of small to medium games. Plus they're starting to work on features like texture streaming for bigger games. It also has an editor which is a big plus for most teams.
Bevy would be objectively better for expensive CPU simulation stuff but realistically what percentage of games need that? Maybe 1%?
For Bevy to catch up on the indie game scene it needs an editor plus a scripting language and/or something like Unreal Blueprints. If it only wants to target the hardcore Rust dev that does everything by code it will never go mainstream.
Godot gives GDScript simplicity for the vast majority of use cases which is that iteration boon, provides C# for games that need the additional guardrails. For performance critical game scripts you can just jump to C++, Rust, Swift, etc.
But most game scripts are not performance critical. Clair Obscur: Expedition 33 swept the game awards last year as an Unreal Engine game made using almost entirely visual scripting (blueprints).
I'm currently messing with some old projects written in Game Maker 5 and let me tell you it would be so much easier if I didn't have to do internet archaeology just to figure out how GML worked 20 years ago.
Example, see all the bad rep .NET and C# get from devs that only know them from Unity, full of legacy stuff and restrictions, instead of using the real product.
Meanwhile to extend Godot usefully you have to use C++ and a plugin API that's arguably no less complicated than adapting an existing language as the scripting language would have been.
Sure if you only want to target desktop/laptop computers, you're safe.
A lot of people complain about OOP, but it's a paradigm very well suited for rapid development.
Maybe it's the "ancient" part, because more recent is always better ;)
Starting with absolutely nothing but a compiler is always going to be a worse experience (and less likely to result in anything released) than a GUI-driven and aided solution. If Defold developers had produced a fraction of the libraries that Godot has, it might have had a chance. As of now, it's worse than other abandoned engines like Solar2D (was CoronaSDK) for people entering the space. As most people know, the vast majority of games are net-losses, so engines live and die by the ease of adoption by newcomers.
I don't understand what you mean by this -- Defold has a graphical editor?
> If Defold developers had produced a fraction of the libraries that Godot has, it might have had a chance.
What do you mean by libraries in this context? It has a robust plugin system with a reasonably active ecosystem, if that's the sort of thing you're talking about: https://defold.com/assets/
And it covers all the systems one would expect in a 2D game engine natively -- tilemaps, physics etc.
> As of now, it's worse than other abandoned engines like Solar2D (was CoronaSDK) for people entering the space.
I definitely disagree with this -- it's certainly not abandoned, and though it does have a slightly steeper learning curve than Godot or other popular engines, that's also how it gets such impressive performance and slim builds; feature, not a bug.
(it is only extension support -- not scripting -- but the extension system is such that it can be used for any game logic AFAIK)