I would like structs mentioned before, I ran into the need for something better than a dictionary, and classes are heavy.
There are editor issues and bugs surrounding the scripting languages. I found that if you use a local function or property but add the “self” , like self.<func/prop>, the compiler check won’t catch issues anymore. But this isn’t a language problem.
Other then that I don’t have a lot of complaints. If I think about languages like c++ where more and more features are being tacked on to give an ever more nuanced control over memory, data handling and code production (templates). I got all the basics I need with gdscript. I don’t need a bunch of fancy things, but I don’t like the idea of doing everything in a dynamic scripting language. I feel like at some point I’ll need something better and I’ll probably just go native with an extension.
You can just not on some methods of native classes/nodes, Godot 3 you can do it for all methods.
Method overloading is achieved by providing default values to a parameter list and from the calling side choosing which parameters you are passing. (Ah that reminded me, I want named parameters like Python cause I hate having to provide values for in between parameters!)
It would be nice to have the parameters to be part of the function signature, but I feel like that is minor inconvenience since you may need to write a different function for each function signature, and even if you don’t you can pass the dynamic type anyway.
Custom classes you can override custom methods, native classes can only override virtual functions, like _ready for example. And there are some special classes that are name < class >Extension that expose overrideable virtual functions. I think they did this mostly for performance reasons as virtual functions come at a cost.
I’ll add my “just scrap it” opinion. GDScript falls so short in terms of usability. I’ve personally switched to using C# only in my project, even though it’s not a favorite language of mine. It’s still a whole lot more usable than GDScript, and it comes with one heck of a useful package and tooling ecosystem, far more robust than GDScript’s.
I’ll certainly acknowledge that GDScript’s Python-style syntax and deferring many errors to runtime is going to be more approachable to most beginners than the relatively more verbose, more picky, and unfortunately strictly OOP code of C#. But at least personally, I have a lot of things I want from an engine much more than friendliness to others who are less familiar with programming. There are heaps and heaps of beginner-friendly and low-code game development tools already out there, while production-ready game engines are in woefully short supply. I would much rather that Godot be focused on further improving its suitability for the thing that’s harder to find elsewhere.
Anyway, some specific things I dislike about GDScript:
One big issue for me was that typo’d attributes on a node were producing a runtime error instead of a build error, making them unnecessarily difficult to find and to debug.
And I find it extremely questionable that built-in class names are absolutely uncompromisingly reserved - you can’t even define a class Node as an inner class accessed via ParentClass.Node. (Sure, you can name it something like Element instead, but then what happens then when Godot adds an Element built-in type in 4.XX?)
Trying to override the default to_string method on a class being flagged as a syntax error sure is some kind of language design decision.
In my ideal world, Godot would:
Make C# the default, first-class citizen.
Make it more convenient to write and interface with C++ for performance-sensitive parts, with Unreal-level out-of-the-box-ness.
Keep GDScript around for those who like it, and for backwards compatibility with already existing resources, but freeze it and just let it be.
Consider adding officially maintained and documented JavaScript, Python, and/or Lua bindings to supersede GDScript as the more beginner-friendly entry point for code.
To not repeat things that other people have already mentioned, my only gripe with GDScript is its lack of error handling and bubbling, which is present in many other languages. Even Rust, which doesn’t have try-except, still gives you a Result template class so that you can catch non-fatal errors and whatever message they may contain.
In GDScript, you can’t even pass a message alongside an error without using some other convoluted means.
Programmer of almost a decade here. I’ve contributed to multiple engines, including Godot.
I think the language itself is fine. It’s not trying to be an ultra-performant number cruncher or verbose data structure manager. It’s designed to be a simple, easy-to-understand, integrated scripting language that takes you to your desired results on the way the engine was designed as fast as possible. I think it does that well. I don’t think it should be removed. Maybe a little less… prioritized? But definitely not removed.
I’ve yet to run into any syntax or language-level issue like needing typed Dictionaries or such, but I’m not denying they might be problems. I’ve just personally not run into an advanced-enough use case to need them.
HOWEVER
I think the tooling for GDScript is absolutely horrible. I’m talking specifically about the built-in code editor. The whole thing feels more like an afterthought compared to the rest of the engine. It’s something I would really like to see improved.
Is there any loop in GDScript that always iterates through once BEFORE it checks the condition at the end?
In VBScript, there’s a Do-While loop that runs through once before it checks the loop condition. If condition fails, it keeps going. If condition is true, it loops again.
For example:
i = 1
do
→ i +=i
while i < 2
print("i = ", i) # Iterates once. Prints “2”.
I guess this could be avoided by having a way to break out of a loop early under x conditions.
As someone who develops addons, the lack of namespaces is a big issue for me. I have hundreds of named classes in my larger projects, and have gotten several bug reports due to name collisions between my addon code and user’s preexisting code.
I’d also like to see a much more robust handling of names in GDScript. I like to use strong naming conventions whenever I can to keep things clear and catch bugs at compile time. Unfortunately, GDScript behaves weirdly with class names and seems to assign them to the wrong objects from time to time. My biggest addon - Cyclops Level Builder - cannot even load properly the first time and I have to have complex work arounds for users that include reloading the project multiple times and manually setting an Autoload.
Autoloads are another weird feature. Singletons are necessary for parts of the program, but Autoloads conflict with the class_name system. So if I have a scene that I autoload as Globals I cannot then also give it the class_name Globals. I have to name it something else or not name it at all.
It would be nice to see GDScript overhauled so that using class names was central to how objects work and everything else worked neatly with that. At the moment class names seem more like an after thought that are constantly causing things to break.
I agree. I really do not like dynamic typing either. There are a few places, though, where the API’s design forces to you pass bare objects around. Maybe they could do something like Java and automatically make every object inherit from Object.
Labeled breaks and continues would be another great addition. Sometimes with nested loops you need to break out from more than one level at once. At the moment, you need to work around this by setting flags.
My number one request would be interfaces (as OP said). I’m not sure if this was omitted because of dynamic typing…?
Overall I really like GDScript and Godot, but I don’t see any value in dynamic typing. It costs so many other things, like proper refactoring and error checking. If I type out a method that doesn’t exist on a object that I’ve statically typed, Godot should call me on it. I have a feeling it’s set up this way because Godot is very duck-type / composition forward… but I’d much prefer that if I’m statically typing everything that Godot play along. To me, there’s no value in assuming the best of my code and trying to make inferences on my behalf when I’m going to be designing everything a specific way.
For example… what’s the benefit to me when Godot fails to throw an error if I try to assign a returned bool (in a function that declares the return type) in a variable statically typed as integer? If I’ve made this mistake, Godot should call me on it. Is it preferable that my game not crash if Godot can try to convert the int to a bool… maybe? It would be much more valuable to just warn me when I make that mistake in the IDE. I’m not sure why dynamic typing is a benefit, personally.
hii everyone
I find GScript’s ecosystem limited compared to other languages, which can lead to challenges finding specific libraries or resources. Type mismatches can cause runtime errors due to the dynamically typed nature of GScript. Performance may also be a concern for CPU-intensive tasks or large-scale projects. And users transitioning from other programming languages may face a learning curve due to GScript’s unique syntax and features.
that is an example of overloading, and it is extremely useful as it will provide accurate api with all options available. That means when using the method it will show you a feedback on the parameter, saying which types it can accept.
your solution will break the type, and force to use a dynamic type in the first parameter, so you check the second parameter which can be marked as an int type, by setting a default value of null so you check if it is null then it was passed only one parameter which is set to be a vector2, other wise the first parameter is an int.
the point is that you won’t get any feed back accurately doing this pseudo overload.
We need methods overload in GODOT!!!
I have used a dozen (or more) languages in my decades of professional development, and C# angers me more than any other. I have never understood why it has gained so much traction. It lacks Java’s portability, and lacks C++'s performance. However, it’s understandable that people who are familiar with it would like to leverage their knowledge of it within Godot.
GDScript is a great intermediary between ease of use and performance. Being an easy-to-parse language, it would be plausible to use it as an intermediary language for conversion to other languages. And getting rid of GDScript will certainly not happen any time soon. There would likely be a mass exodus if that were to happen.
Ifs: I really don’t like the way if’s are structured I dislike having to add the colon “:” same with functions as well I much prefer the braces. And I still add the semicolon at the end to end lines of code.
And one thing I definitely hate is having to use the “#” for comments. Coming from a Java/C++ background I much prefer the use of “//” and “/**/” for multi-line comments. I like to add a lot of commenting to my code/scripts. Changing that would be a great addition for me.
