What were the motivations behind creating GDScript?
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.
GDScript was designed to curtail the issues above, and more.
An additional aspect is that--in terms of language design--in many cases "do what Python does" was the design principle followed, so that helps reduce the learning curve for those with Python experience and potentially helps avoid language design roadblocks during development of GDScript itself.
It's extremely common for people to be resistant to using GDScript initially but then be: "oh, actually, this is really good".
And there's now additional bindings for other languages (e.g. C++, C#, Rust, Python to various degrees of completeness) via the "GDNative" interface that essentially provides a C API for communicating with Godot & passing objects around.
- Bloat... Both are extremely heavy dependencies if you want "the real deal" vs a stripped down version that looks like Python or JavaScript.
- Performance too. Python is slow. JavaScript too, unless you use the modern JITs.
- Licensing perhaps?
- Lack of support for that use case?
- Painful interop? No idea.
I personally dislike the python ecosystem and am not missing anything.
a lot of visual programming environments, like LabVIEW (1986) or Max/MSP (1985), predate Python and JS by at least a good few years :p