Now I’ve never used it, but there’s always a case with an engine with its own objects to have a language that understands those objects natively.

Unreal Engine started out that way.

UE is going to be amazing (It mean it already is, but WAY more so) once verse is integrated into it.

The "so, you have a choice of c++ or drawing lines between boxes" is missing a lot of middle ground :)

Godot has supported C# for a while now. There is no need to use GDScript

Unfortunately Web Export is not supported with C# in Godot 4.X. And probably won't be for a while*. It's the ONLY reason I even bother with GDScript.

https://github.com/godotengine/godot/issues/70796#issuecomme...

And despite my best efforts to statically type everything in GDScript, the language is full of holes that lose all the safety.

I wish that was true. I just started rewriting my project from C# to GDScript today so it can run on 32 bit ARM android devices.

Let's say I'm not a big fan of the language. Why the hell they decided to not implement normal for loops, was just googling how to iterate an array backwards and most people were like "just invert the array and iterate over it, bro"

They should have just used Typescript, it's a sweet spot between safety and productivity.

The docs have an example of iterating an array backwards:

https://docs.godotengine.org/en/stable/classes/class_@gdscri...

    var array = [3, 6, 9]
    for i in range(array.size() - 1, -1, -1):
         print(array[i])

Admittedly not very pretty but it certainly works.

After reading several posts above yours describing the level of effort and pain trying to use this scripting language and how multiple people in this thread avoid trying to use it as much as they can, then reading your small code sample, it's hard to not describe as a level of perception whiplash.

"why god why can't they just have for loops!?!?" and the problem was just ... knowing how to foreach over a range correctly? the idiom and language syntactical preference that python, a language older than java, has done for decades...?

Really trivializes every complaint and the assumed skill level of every person that I see in this thread complaining about gdscript to the absolute lowest level. Thanks for the post!

I disagree.

The doc states that range function returns an Array, so it looks like to iterate backwards you basically allocate array of indices and use those indices to get values from an original array. Not much better than reverting original array, if you will ask me.

Maybe there is some optimization for trivial scenarios, but the referred doc doesn’t mention it.

It really looks like python 2 case when you needed to remember that dict.items() returns copy and most of the time you needed iteritems().

This is one of GDScript’s right spots for sure. But if this is the performance bottleneck (in a dynamic scripting language) you’re facing, then maybe that bit of code should just be a GDExtension, written in C++.

I would imagine for most games the performance impact from this won’t matter much.

The problem in this case is not the potential performance bottleneck, but the bad ergonomics for a dev, that leads to the complain. The rest is consequence.

And to me it looks like pure language/stdlib problem. Like for me, the proposed solution looks ugly both from syntax and what is going on behind curtains perspective.

I would rather not to code in a language that makes/tolerates decisions like that.

I mean if this one thing is enough to turn you off, you do you. I find GDScript to be 98% good for a dynamic scripting language.

Personally I’d just reverse the array and then iterate it. It’s going to make about zero difference.

Every language has its sharp edges.

cpython is slow enough that copying the list of keys was rarely a significant bottleneck

While that's true, the caveat here is that unlike Python, GDScript does not have a garbage collector. The main performance problem with creating an array copy in a soft-real-time application like a video game is usually not the allocation, but the additional GC pressure, which could cause frame jitter. GDScript does not suffer from that latter problem.

I agree! I use both GDScript and C# with Godot, and GDScript is excellent. But, I’ve been programming for 40 years, and my baseline is “all programming languages are bad” :) All I need is a Turing machine with nice ergonomics and I’m happy. I’m very easy to please.

I had high hopes when I saw the yield keyword in the reference, but then saw it's basically just a reserved keyword as they don't seem to actually support generators. I would guess the less eye-bleeding version of all those 1, -1 things is just making a ReversedIter and using that: https://docs.godotengine.org/en/stable/tutorials/scripting/g...

I presume they do for loops the same way Python does? Which takes a couple of minutes to get used to and is perfectly fine. I wish C# did this more like Python to be honest.

Godot lets you use whatever language you want. C# included.

I don't use godot and know more about its limitations than its advocates in this thread. Are they being disingenuous? Do they just not know basic information about their own tools?

GDScript is closely tied to the engine, making it incredibly easy to affect any part of your project. It's also very terse and simple to use, and anyone with a passing knowledge of Python should be able to pick it up in minutes.

I've used C# for my day job for years, but never felt the need to stop using GDScript for any of my projects.