Everyone here please keep in mind, this is not a voting. While it’s fine to discuss what you like/dislike, please keep in mind that this won’t have any impact on the development. Proper proposals can be made in the GitHub repo for that, and for many of the topics here there already are proposals. If you want to support a proposal, you need to add a 
reaction on GitHub. Saying here that you support it won’t do much.
12 Likes
Personally, I’m hoping for Python’s “F-String” functionality to get implemented. Formatting strings is a chore.
Relevant issue:
2 Likes
GDScript needs unsigned int64.
2 Likes
Aside from the aforementioned Typed Dicts and structs how quickly syntax and bespoke functions change. I’m sometimes following some tutorial from a couple of months ago and some stuff suddenly doesn’t work and after some digging I find that it’s become obsolete.
Just one of the downsides of it being constantly improved upon and updated. 
I know Python quite well and I am new to Godot.
On one hand, it was really nice to find a language in Godot that is so familiar to me. On the other hand GDscript is quite rough around the edges compared to Python (and I honestly think that going with tabs instead of spaces was a bad decision).
Here is what I missed in the last two weeks:
1. Functions with multiple return values.
Python internally uses tuples in this case, so you can just write:
def test():
return "a", 42
s, v = test()Dictinonaries are an OK workaround for this.
2. Referencing the scene root
When searching “how can I get the root of the gurrent scene”, one finds dozends of answes saying
get_tree().get_current_scene()But this returns the total root of the scene tree, not the root of the current .tscn-file. I found no easy way to do this.
3. Logging
I am fighting with all my print-statements for debugging my code. I really miss the buildin logging of python, with different loggers for each file, log levels, formatters, writing to different targets etc.
A Godot-specific logging system would be really helpful. It could implement features like:
- Output logs from a node only each n-th frame.
- Optionally store log output in an internal buffer, without printing it live (which consumes resources). It could be made searchable after the fact.
4. String formatting
This is still about fighting with my prints. First string formatting is buggy, if a format string contains an error, you instead get the output from another format string (maybe Format String Grabs Latest Local String Variable when Erroring out due to insufficient arguments. · Issue #85498 · godotengine/godot · GitHub ?).
Also the %-based formatting is what Python did 10+ years ago. I really miss modern f-Strings, especially the f"{variable=}" syntax, which returns "variable=value" and is REALLY handy for debugging.
5. Refactoring in the editor
Renaming variables and functions in the editor would be really handy. Currently there seems to be only “stupid” search-and-replace, which does not know what the symbols are and does not rename references to the same variable in other files.
Curiously this feature is available when using VS Code with Godot as language server.
7 Likes
just a clarification
I’d rather they scrap the weird proprietary
GDScript is not proprietary, is free and licensed with MIT as the rest of the engine
7 Likes
@joviansettler a few of those things are already possible:
- The
ownerproperty specifies what a node belongs. In the case of scene files, this will be the root node of the scene file. - While we don’t have the same as python logging, you may be interested in these functions (especially the last two are super useful as they utilize the built-in debugger):
print_debug()printerr()push_error()push_warning()
4 Likes
This one is not a big deal for Games but only for Functional Programming.
GDScript has first class functions, but closures still don’t work.
And thank you for not making C# as the First class language for Godot by not falling into the temptations (Famous, Faster, Richer, Bigger, Better) of the C# Evangelists.
1 Like
Following the trend of “lack of typed X”, I’ll add lack of types for PackedScenes.
I just want to be able to click “quick load” on an @exported PackedScene and have the editor only show me the ones who extend ItemPickup instead of all the several hundreds of PackedScenes in my game.
3 Likes
@jydvfg do you have examples about this? The only syntax change in GDScript was made in Godot 4.0. There are some cases where things were added in other versions, but nothing that broke old scripts.
Now, if you mean classes and functions that change, this is related to the Godot API, not really to the language itself. Though this also does not change much expect between major versions.
The main problems in this regard is the switch between Godot 3.x and 4.x which indeed has a lot of breaking changes, both in syntax and API. But other than that I don’t see breaking things happening often, much less in GDScript itself.
1 Like
Dynamic typing. I’m a strong fan of static typing since it allows one to keep code predictable. Optional types are not enough.
6 Likes
Lack of a Built-in Code Formatter.
8 Likes
Personally, I’d like a ref-type for primary types. Occasionally, at runtime, you want to do things to an int or a float and have everything else update accordingly.
Also, personally, I think features of the language are getting a little bloated. I don’t really like signals. I’d rather go through an array of function pointers if I want that kind of functionality. Now that we have Callable types, why bother with signals?
Other aspects of GDScript stink of an identity crisis - like between making objects through inheritance, or making it through composition. Personally, I’d have preferred if they worked out the problems sufficiently to do everything by composition without the need for inheritance.
Likewise, I wish they’d made up their mind about whether composition takes place by defining properties in nodes, or in the tree. I hate having to flipflop between "" separated Node paths and “.” separated properties and dictionary fields. I’d have preferred if there was just a single main composition data-type you inserted functionality into., a bit like tables in lua.
The way Godot handles concepts like globals, singletons, namespaces, and using directives is annoying. Mostly, it doesn’t. It’s can be difficult if you just want to conjure up some data or functions and not have to worry about wandering through some God forsaken maze of nodepaths to find anything. You start thinking, "Should I make a class with some static functions? Should I add yet another Autoload and keep cluttering the tree with them? Should I add children to an existing Autoload? Things get really messy, really quick.
1 Like
Seems to work fine for python. As long as offering both types of typing doesn’t mess things up (it doesn’t) then why not keep both?
While you might not understand the reasons GDscript remains primary (and loved by many, if not by you) there’s no reason that it and C# can’t exist peaceably together in Godot. The argument that “GDscript” takes away from other more vital stuff!" honestly doesn’t hold much water.
2 Likes
more than that, the use of PackedScenes as classes could improve abstractions and allow more generic scripting, but that might be out of GDScript’s scope.
1 Like
Not agreeing with the decision or reasons doesn’t mean i don’t understand them.
Suggesting a silly “complete removal” of GDscript does suggest that one prioritizes their own desires over the fact that it works well for many is is generally well liked.
And the idea that “OMG if they support GDscript, no other priority features will happen or be improved!” remains well… wrong.
6 Likes
If I may, just comment on a few things that stood out.
This is a user error and has nothing to do with language of choice.
I am 2 months into dev of my game and I have zero magic strings referencing any node paths, and 0 times I’ve used get_node(). Node paths are a shortcut for quick prototypes, but imho they should never be relied on in production code. The only (optional) exception are “guaranteed” nodes; for example my Level scene will always have a Timers node and an Enemies node, so in those cases I allow myself to not use unique names and do:
@onready var hit_display_timer: Timer = $Timers/DisplayHitTimer
In all other cases I use unique names feature b/c I never want to be worried about messing up my code if I modify my tree structure (especially for UI scenes):
@onready var attack_box: AttackBox = %AttackBox
Lastly, all nodes I need to reference in code are defined via @onready variable at the top; I never allow myself to do $Timers/DisplayHitTimer.timeout.connect(..) in a method somewhere. Nope, not ever. I always reference the variable instead, e.g. hit_display_timer.connect(..) Hard-coding node paths is just asking for headache down the road.
Every language has features like that - features that are okay sometimes / in small apps, but not okay for bigger/more complex applications. Just skip those features if you want a more robust codebase.
While at some point there’s such a thing as too many global objects, I’m not sure how 5-20 singletons are a problem when any complex scene will have hundreds of objects anyway. Plus, singletons usually don’t store any image or sound data so they take up little memory. And their code isn’t run every frame, so they don’t take up CPU cycles either… Finally, many singletons (such as AudioManager) save you from having duplicate objects (AudioStreamPlayers in this case) scattered across your nodes. Unless you’ve designed your singletons in a way that violates other good design principles, I don’t see how singletons can be a performance bottleneck for an app.
Regardless, the language doesn’t encourage anyone to create a ton of singletons - it simply provides a way to do it when they are necessary. By necessary I mean the right mix of dev cost (i.e. speed), maintainability, and function, which will differ from project to project.
7 Likes
I like GDScript quite a lot, but I think if I were to change one small item, it’d really be more of an editor/syntax tweak.
I find the method for defining default values for functions to be a little bit verbose, and it’d be nice if when you call that func it let you know what the expected values are.