I disappointed that GODOT team keep investing resources into this cumbersome programming language .
its contrasting every basic software rules : like not inventing the wheel …
any way … c# have huge ecosystem .
And if they realy want to be with adge … improve c++ interaction
Why keep investing in GD script is behind me …
2 Likes
Because a lot of people (me included) love GDScript. You don’t need to like GDScript, but please respect that a lot of people really do. This whole thread you are replying to is people wanting to improve it. There is demand for it.
Also keep in mind that you can’t just reallocate the resources we have for GDScript to work on C#. This is an open source project, and the people working on GDScript are passionate for that, not for C#. Chances are they would just leave the project if support is dropped. That would not improve C# in any way.
Both languages can co-exist. Having people that work on GDScript does not make the C# support worse. If anything, having multiple languages makes the engine accessible to a larger range of people.
15 Likes
so did Pascal and Basic 
7 Likes
I mean this from the company’s perspective. Financially, it makes no sense. Just imagine the resources required to maintain such a bizarre script when battle-tested industry standards are already available.
But how many billions of dollars they help to made over the years ?
don’t thing DG script will be any time soon near this …
This is an open-source project - the maintenance is in large part done by the community. For free =)
7 Likes
Sure, I know; this even strengthens my point.
I guess there are less knowledge and experts and more problems when supporting bizarre programming language .
And more experts and problem solved in well proven Ecosystem .
From my yet unskilled view, I must say, it’s very easy and convenient to get into gdscript while it’s hard and intimidating to do the same with C#. (Minus the indentation and lack of curly brackets for code blocks…)
And for that low barrier of entry alone, I think it’s worth it.
As many have stated: it’s not like the development costs a lot of resources. It’s the same with the extensions for other languages: the people developing those are doing so, because they are interested in that and not gdscript or c#
Just my 2cents from my beginners perspective
6 Likes
Look for a code formatter if you use VSCode / Community or something that can format documents. You just paste it and format on save. No need to manually edit stuff.
2 Likes
Like comparing a glass of water to a bucket. 
1 Like
Like winston said, I don’t think there’s any point discussing whether GDScript should be in engine or not, or making guesses on how resources could have been allocated differently, or trying to convince anyone that this is the “right” or “wrong” decision. Not everyone will agree with every choice that the contributors and maintainers do, and that’s okay. We can agree to disagree on it 
8 Likes
I completely agree. Also, no one is forcing anyone to use GDScript. It is even possible to build the engine without GDScript support, if someone only wants to use C# (or other languages) in their projects.
5 Likes
I will also add a little to this controversy. I personally think that GodotEngine is so popular because it has built-in GDScript and it is very easy to learn it quickly and especially to use it and get quick results.
@winston-yallow wrote here that you need to ask the github team. But I’ll write here anyway. It’s a slight analogy with MicroPython(MP). Each script has its limitations because it’s an interpreter. MP also has its limitations but it has one nice feature and that is calling into the CPU core in our case it is RP2040 which has two uninitialized cores. These can be filled with ASM code directly in MP via a given call.
And what could this have to do with GDScript? For complex operations like executing some complex calculations, call the “API” via GDScript to the GodotEngine kernel which works in C++ and had some tray ready in it which would expect ASM calls.
So GDScript as an interpreter would call the API to the GodotEngine kernel with a given set of ASM statements.
But this is just an idea.
For me, GDScript is perfect and I don’t need anything else in GodotEngine. 
6 Likes
Lack of List. It’s so basic. Array is not always nice (performance-wise).
6 Likes
I agree in the sense that GDScript looks a lot like Python but lacks almost all of the features that make Python fun and powerful, especially the many clever and mature ways to work with lists and other data structure, plus things like slicing.
On the other hand, Python is slow and most of these features are not that relevant in game development where performance is important. And an array is in most cases hard to beat performance-wise.
3 Likes
The more I use GDScript, the more clumsy it feels to be honest. Python is a far more elegant language. Some essentials that Python-Programmers use all the time are:
1. Unpacking of - in Godot’s case - Arrays
var a = [1, 2]
var x, y = a # x becomes 1, y becomes 2
This has already been proposed here: Add array unpacking/destructuring to GDScript · Issue #2135 · godotengine/godot-proposals · GitHub
It would also enable simply returning multiple values from functions.
func my_func():
return 1, 2
var a, b = my_func()
2. Enumerating Array Elements
for count, value in enumerate(some_array):
...
This has been proposed here: Add a python-like `enumerate` option for iterators · Issue #7651 · godotengine/godot-proposals · GitHub
3. Looping over Keys and Values of a Dictionary simultaneously
for key, value in some_dict:
...
This has been proposed here: Add support for looping over dictionaries' key and value (`for key, value in dict`) · Issue #3457 · godotengine/godot-proposals · GitHub
One more thing
Another idea that I would consider useful are interfaces.
There is a proposal here: Add a Trait system for GDScript · Issue #6416 · godotengine/godot-proposals · GitHub
This trait system partially has other intentions, but it also wants to add abstract functions that could be used as a replacement for interfaces.
2 Likes
Except when you need to insert/remove elements often. You can use a separate array of indexes, but it sucks to waste time on this, when you just want a good old List.
1 Like
No “{” and “}”
2 Likes
Lack of Method Overloading and Method Overriding in GDscript
1 Like
some things I’m not a fan of in GDScript when working on larger projects:
- lack of static types. Its more akin to typescript. Makes refactoring a headache. Far better than no types, but could be better.
- lack of stricter compiler rules. There’s classes of bugs that don’t exist in a statically typed lang that you have to contend with in a non-static one. Particularly with scenarios where the only way you’ll know something is wrong is at runtime, when a compile time check or lint would’ve made it impossible to get into that state.
- lack of errors as a first class types or optionals.
that said, the speed at which you can knock together prototypes with it is amazing. And with the above, in my experience languages that offer those features tend to slow down that velocity/ease of use.
4 Likes