I don't understand why they're calling out the FPS of an empty scene as a useful number compared to Unity though. Ignoring that this engine will have a fraction of the features of Unity (the likely reason for the FPS number in the first place), it's just a useless benchmark because it's an empty scene. `while (true) {}` will get you the same thing.

I'd wish they'd highlight how the engine helps you make a game rather than arbitrary performance numbers on microbenchmarks that don't generalize to a real game project. You can absolutely be faster than Unity, but "9 times faster than Unity out of the box" is not a number people should take seriously without the context of where the number comes from.

I wish them well though. I'm always interested to see more work in implementing engines in GC languages. I'm personally quite interested to see what can be done in modern GC languages like Go or (modern) C# which provide lots of tools to limit GC pressure. Being able to write C-like code where needed in an otherwise managed runtime is a really powerful tool that can provide a best-of-both-worlds environment.

When an engine becomes useful is when it has to make a game. All your abstractions tend to get rearranged and hard decisions are made.

https://unity.com/ leads with demos.

https://kaijuengine.org/ leads with a block of text claiming it renders cubes faster than Unity.

Are there a lot of Unity/Godot devs unaware that their engines are using GC? I would assume they'd have accepted the cost of GC already.

Unreal devs I can understand having an issue with it though.