[dandellion]

They're commited to GDScript because it's a great scripting language. I started with Godot expecting to switch to C# pretty fast because I'm already familiar with C#, but I was pleasantly surprised with GDSCript. And I'm a programmer with more than 10 years of experience. For people who are still learning it must feel like the difference between trying to learn to ride a bycicle vs learning to fly a boeing 777.

[krapp]

GDScript not a great scripting language. It's an adequate scripting language whose only benefit is native integration with the client, and guaranteed support in perpetuity. But there is nothing about it that's better than any other scripting language. No one would choose to use GDScript as a general purpose programming language.

Other scripting languages are also easy to learn. Vanilla Javascript is much easier than GDScript. And so is Lua. Kids learn coding in Lua. Even Python isn't that difficult compared to C#.

[dandellion]

I'd argue it's better than Boo and better than Blueprints. Maybe even JavaScript, because JS has made itself very useful as time has passed but as a small scripting language embedded in browsers it sucked.

It's only benefits are native integration with the client, and guaranteed support in perpetuity, and it's easy to write, and easy to learn, and teach, it almost never surprises you in ugly ways (which is awesome), it comes with a good enough debugger, its library pretty much covers what you need to make your average indie game... But what did the romans... I mean, GDScript, ever do for us?

[johnnyanmac]

>its library pretty much covers what you need to make your average indie game

Hey, if GDScript could run my idea for a 3D Open hub Action RPG at 60fps with little concerns for performance, I'd have no issue.

But alas, my desire for a proper binding or directly tapping into the c++ comes out of necessity, not some pride as a "real game developer". It's not impossible for GDScript to one day become the WebASM of Godot, but we both know that WebASM was, and still is, decades in the making. I imagine it's simply faster to forge a fast path API and let the slow path work for non-performance intensive games.

[krapp]

It's like you believe GDScript is the only language for which any of these features are possible. Other languages are also easy to write, learn and teach. Integration with the client is an implementation, not language, issue. Support is a business issue. Debugger quality is orthogonal, and you can make a game in assembly if you want (Railroad Tycoon.)

[dandellion]

Those are your words, not mine. The thread was talking about ditching GDScript in favour of C# and comparing it to other engine scripting languages. You want to go with the conversation on a trip to the mountains, you go alone.

[krapp]

You're being weirdly aggressive here, and you have yet to actually address any specific point I've made in any of my comments, much less defended your own, so I'm going to call it a night.

[dpig_]

You've been just as weirdly hostile from the jump.

[mardifoufs]

Not being rhetorical or snarky, but what do you like about gdscript?

[dandellion]

If you know how to code it's very easy to learn, it doesn't matter if you come from C#, C++, JavaScript, Python or something else.

There's almost no nasty surprises. Nothing like learning JavaScript and then discovering the weird behaviour of this, or using Python and discovering for the first time that the weird bug you had was because you set a dictionary as a default value for an argument.

It's got some of the syntax sugar you might expect from modern languages. Not as much as Python, but that might be for the best if they're trying to keep things simple.

Some of the syntax sugar (@onready, $, %) is specifically there to integrate with the engine and it is very very nice.

Documentation is good, integrated with the editor and the inspector.

The debugger works well (98% of the time, hopefully it'll keep improving).

It's one of the nicest languages I've learned in a long while. I think it's because it's only trying to do one job and it does it fairly well.

When I started learning it I noticed many things that were done better in other languages I've used (it's specially tempting to make comparisons with Python since it looks similar). After a few months using it almost daily to make a somewhat simple game I realised most of those things don't matter and for the purpose of making games in the engine it's pretty solid.

[danbolt]

I can’t speak for the parent, but @onready combined with the $ operator is a delight when making a prefab.

I also very much like the way signals are declared compared to C#’s code generation.

I’m also a fan of TypeScript, so being able to do gradual typing while prototyping is a huge plus. It’s going to be a big advantage if they ever get JIT.

Everything being reference-counted, rather than fretting about GC pauses is comforting too.

[janosdebugs]

Also not the parent, but: It's a very simple language. It looks like Python and behaves like TypeScript. It makes it easy for beginners to get into game development without having the visual overhead of a C++ or C#.