What do you DISLIKE in GDScript?

Is there anything you don’t like or miss in the current state of GDScript? Let’s constructively discuss it to see which features are wanted and can be prioritized.

Currently I’m dissapointed (concerned) by this:

  • lack of typed dictionaries is an abstraction leak;
  • no interfaces for better level of abstraction;
  • String-typed (and other value-typed) variables cannot be null (there is such proposal already).
7 Likes

Lack of structs.

Not having it was a hassle for me when transitioning from GameMaker Studio 2 to Godot a few years ago, I made heavy use of them in my games. Same thing for lambdas, but they are finally supported in Godot 4.

15 Likes

ninstar, yes, structs would increase performance and code safety (due to the compile-time check of the structure properties instead of dictionaries). There is a proposal by reduz about structs:

8 Likes

Typed dictionaries PR: https://github.com/godotengine/godot/pull/78656
Traits proposal: https://github.com/godotengine/godot-proposals/issues/6416

9 Likes

eons, thanks for links. I like the traits proposal, it allows to treat traits as interfaces:

Besides that, it [trait] can include method signatures, which are methods without an implementation defined, making the trait acting like an interface.

2 Likes

Your third point there is really my big one. I tried to think of something else to add but actually I’ve been really enjoying learning this language and don’t have much negative to say! Compared to C# it’s been an absolute breath of fresh air.

Glad to hear there is discussion around making more types nullable though, that would be a big help.

1 Like

Structs and typed dicts are big ones.

In addition I found the different scopes and when to use what around class_name, inner class definition and autoloaded scripts confusing at first. Makes a lot of sense though, it just took a bit to click for me.

Also not being able to pass Resources in RPCs.

4 Likes

Honestly, all of it.

I’d rather they scrap the weird proprietary language and just promote C# to a first class language. It’s the same dumb shit Unreal is doing with their ‘Verse’ scripting langauge, but it makes even less sense. GDScript will literally never reach the same level of robustness or tooling as C#. Not because the devs are bad or anything like that, but just out of a sheer volume of work-hours and funding spent tooling C#. Same with their pseudo-in-house GLSL solution.

With a small team, and especially with limited funding, you don’t want to spend time doing things that don’t contribute to your MVP. People can script just fine in C#; we don’t need GDScript. What the engine needs is improved rendering, improved tooling for animation work, improved texturing and shading, improved in-house physics, improved asset pipelines, etc. And time spent making GDscript a thing is time not spent on more critical improvements.

2 Likes

It begs the question “Why traits? Why not Interfaces?”

Have you read the docs on the motivation behind GDScript? It’s not just a fun side project of the devs.

12 Likes

FWIW, C# is not that well suited for game development. Refcounting is much better performance-wise than waiting for GC to lock the system with a big cleanup.

Godot is not developed by a “small team”. As an open source project, it’s pretty big. Just look at the number of contributors at each dev update, or at the number of waiting pull requests. The problem is more that not everything will appear in vanilla Godot, since being lightweight is one of the goals with Godot.

5 Likes

Yes, and I still think it’s a bad idea; even it has a good-sounding justification.

4 Likes

Hard disagree, literally look at any comparison between GDScript and C# (and that’s with the current anemic c# implementation). But my point wasn’t about performance; it was about time and effort. Also, just so we’re on the same page: stop-the-world isn’t the only garbage collection option in .Net.

Interesting that I keep seeing the same 15-ish names on their page listing the team working on the engine, then: Teams - Godot Engine. Maybe they could spend the time they save by dropping GDScript to start working through the pull request backlog.

Keep in mind, those are not the only ones working on it. Just the ones having an in-depth knowledge of that area and being in that GitHub team, so those people can review PRs for the specific area. This doesn’t mean they are the only ones writing PRs. There’s a lot more contributors!

On another note, I don’t think dropping GDScript will ever happen. After all it’s one of the main reasons many people use Godot. I for one don’t want to miss it. Raw performance comparisons aren’t important to me. I don’t care if something else has more performance, since GDScript has enough performance for me. And in those rare cases where it doesn’t, C# didn’t have enough performance for me either. So in those cases I mostly used Rust via GDNative/GDExtension.

13 Likes

I don’t either.

1 Like

16 years of dev experience here… started with html/js, then asp/visual basic, then C#, then objective-C, some C++, then a little Swift, and now GDScript.

Each language has pros/cons, and C# - despite it’s ugly syntax and crazy capitalization conventions - is decent, and it does have good performance, but to state that C# is the best for serious game development with it’s garbage collection issues is a little off-mark, imho. If we’re going to promote a first-class language, we should be promoting Swift (or, some would argue, Rust).

That said, I LOVE gdscript. Godot isn’t meant to compete with Unreal (thank goodness); it’s a tool for different kinds of jobs. And simplicity is very important when it comes to speed of development, an area where gdscript absolutely shines. It’s easy to understand, beautiful to look at, etc. - those things do matter. If they hadn’t, we’d all be writing in C++ still.

I’m very grateful for gdscript and absolutely want its development to continue. My only wishes are increased performance and smaller stuff others have mentioned - structs, typed dicts, etc.

I definitely sympathize with the desire to focus more on core engine features and stability. I just downloaded 4.2.1 and my game crashes back to desktop, yet works fine in 4.2 lol. So sure, there are rough edges. But people passionate about developing gdscript aren’t necessarily same people also passionate about adding core features; if they aren’t allowed to work on gdscript, they may just leave and do something else entirely. So…

22 Likes

I am a new GDScript user, and personally the only thing I dislike so far are the indentations. They’re super annoying and when I ask AI for code suggestions, I have to replace all the spaces with indentations, and I have made some huge messes with indentations. Though there’s probably some 4000 IQ reason GDScript uses them and I’m just stupid. Feel free to tell me in stupid detail why I’m wrong.

1 Like

The reason they use tabulations is because 1 tabulations is 1 character but if you use spaces it’s 4. You’re basically saving a ton of space which also make the code run faster.

2 Likes

Things I want in GDScript:

  • Typed Dictionaries.
  • Structs.
  • Defining Nested Typed Arrays. Example: Array[Array[Node]]. For some reason you can only go one level deep.
  • Casting untyped Arrays to Typed Arrays without having to rely on array assignments. Example: Being able to do untyped_array as Array[Node], which would be nice when using bytes_to_var().
  • Traits.
  • Union types.

I also don’t like that typed variables can be set to null and that functions with return types can also return null. Makes it impossible to know if you should be checking for null values when looking at function signatures and can lead to unexpected and unhandled null values causing issues. Ideally this should be handled by having functions that can return null have a return type of a Union of null and the other type.

I also wish that the type inference in GDScript were better. For example, in the following code snippet, it is not automatically inferred by intellisense that the node reference right after the return statement has the position property for autocomplete (which it should), but the node reference inside the last if-block does correctly autocomplete the position property.

func check_node(node: Node):
	if not node is Node3D:
		return
	
	node.position

	if node is Node3D:
		node.position
5 Likes

Going to add another vote for “typed dictionaries” onto the pile. Would be super useful especially as I’m using a fairly complex dictionary for some static data that I reference on certain user actions.

Other than that, I like GDScript a lot and would hate to see it be cast aside for language like C#. And I know a decent amount of C#! There’s a reason people like it so much, and as much as I’d also like to see C# become more integrated, I’ll still prefer GDScript when (not if, when) that happens.

6 Likes