Also C# is available as a scripting language for Godot, which makes a lot more sense than python from a performance perspective.
It seems like they tried to do Python, but it was too hard to embed. The FAQ goes into more detail about the specifics of what they needed in a language.
[0]: https://docs.godotengine.org/en/stable/about/faq.html#what-w...
It’s not uncommon to see your typical engine have a script VM with some API calls into C++ and call it a day. GDScript’s syntax and semantics are a lot more integrated with how Godot does things. You start to see this when creating new Node/Resource types and stuff like the $ operator.
If people want to use python instead of GDScript they are free to do so.
I made a very, very simple game in Godot 4 with my friend this fall. To build for the web target, I ported our C# to GDScript, and it wasn't so bad. The resulting webstuff was 50MB without audio.
I ported it again to JS, and it's 50KB without audio. Maybe 150K with audio. About the size of two favicons.
Yes, the game is very very simple ( https://rezmason.net/fluid , still refining it), but the difference between 50K and 50MB is still significant.
If we had used some kind of Python to WASM toolchain, I don't know what size the project would be, but probably more than 50MB. With C# in the mix, and mono, or whatever, it would be even larger.
One of the reasons we explored Godot this year was to try other ways of producing things. GDScript helps maintain Godot's distinction from its competitors, and I'll reach for it whenever I need to make #ThatKindOfThing.
That sounds about right for a full engine build before compression. When optimizing for size with Godot you rip out the parts of the engine you don't need. From what I remember some of these are not that hard to remove like 3D support. It still will be more than what it would take just doing it from javascript so you would want to make sure Godot is actually bringing value to the project.