This has been repeatedly said throughout Godot’s development history, but there are several crucial reasons as why the team was motivated to create their own sc

This has been repeatedly said throughout Godot’s development history, but there are several crucial reasons as why the team was motivated to create their own scripting language. From the FAQ (https://docs.godotengine.org/en/stable/about/faq.html#what-were-the-motivations-behind-creating-gdscript https://docs.godotengine.org/en/stable/about/faq.html#what-w...): In the early days, the engine used the Lua scripting language. Lua is fast, but creating bindings to an object oriented system (by using fallbacks) was complex and slow and took an enormous amount of code. After some experiments with Python, it also proved difficult to embed. The main reasons for creating a custom scripting language for Godot were: - Poor threading support in most script VMs, and Godot uses threads (Lua, Python, Squirrel, JavaScript, ActionScript, etc.). - Poor class-extending support in most script VMs, and adapting to the way Godot works is highly inefficient (Lua, Python, JavaScript). - Many existing languages have horrible interfaces for binding to C++, resulting in large amount of code, bugs, bottlenecks, and general inefficiency (Lua, Python, Squirrel, JavaScript, etc.) We wanted to focus on a great engine, not a great amount of integrations. - No native vector types (vector3, matrix4, etc.), resulting in highly reduced performance when using custom types (Lua, Python, Squirrel, JavaScript, ActionScript, etc.). - Garbage collector results in stalls or unnecessarily large memory usage (Lua, Python, JavaScript, ActionScript, etc.). - Difficulty to integrate with the code editor for providing code completion, live editing, etc. (all of them). This is well-supported by GDScript.