TLDR - Godot’s raycasting is considerably more memory intensive than Unity’s. Using the Godot API to call its raycast in any language is much slower than simply using the builtin Node. Most of the performance woes are due to how GDScript is implemented: a slow, interpreted language (Python)

It’s a fair complaint, Godot is far from perfect in many areas and may not be ideal for certain projects. This is fine, really. If it’s possible to make the engine better, I hope the pull requests that do so get accepted

He did a small complaint that GDScript should be ditched. If you care entirely about performance, that is true. The problem, obviously, is that a lot of people, me included, rely on it instead of C#. For all intents and purposes, this is something that could be done, but it’d end up as a wholly separate branch of Godot that would end up with several incompatibilities, eventually becoming a different engine. In that case, it might be better to just check an alternative like Stride3D or Torque3D

Necessity is the mother of invention. My hope is that Godot sees more devs wanting to contribute to the project since we’ve now seen firsthand what being under a corporate umbrella can do to your product when it’s not your own umbrella.

UPDATE: This article has started an ongoing conversation with the Godot devs. They care about the issues raised, and would like to improve things. Significant improvements will almost certainly be made, although it’s still early days and it’s unclear what will change and by how much. I am encouraged by the response. I believe Godot’s future could be very bright indeed.

Well that’s nice to see so quick