Hacker News Reader

Comment by krapp | Hacker News Reader

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#.

View on HN

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?

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.)

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.

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.

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

>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.

Reply on news.ycombinator.com