GDScript is designed specifically to be used as the high-level language for implementing game logic in a video game. This is something that's rather unique; virtually every other language used for game development was originally intended to solve other problems: Lua for industrial automation, C# for taking over Java's niche in server applications and enterprise software, JavaScript for enabling supply chain attacks, C++ for getting rid of your remaining toes, etc.
A lot of the "ugly" part in this article is the same as in Python, which GDScript draws inspiration from.
GDScript is easy to learn with a syntax similar to Python where the code is indented rather than using lots of brackets and semicolons. -- https://gdscript.com/
I think the background is important. The author came from a TypeScript background and also likes to write functional-ish code, so they noticed things people coming from a Python background will probably just take for granted.
Though using GDScript as a "quirky Python", one will also soon realise how underpowered this language is in other aspects.
A lot of the "ugly" part in this article is the same as in Python, which GDScript draws inspiration from.
Most of them are not in Python at all. Indentations and the callback pain is the only one which is. And Python has shorter anonymous functions but straight gives up on multiple statements in anonymous functions, though named functions have essentially no limitations, they're just more verbose.
Python
has much better typing support, it's verbose and far from perfect but e.g. it supports generic callables and higher order functions just fine, if you map a Callable[[int], str] onto a list[int] you get an Iterator[str] (specifically a map[str])
has destructuring assignment, though only positional
has inner functions
has no call/callv nonsense
has "a spread operator" (two of them in fact)
and they work for constructing collections, I can't really say that Python is great at immutable structures but it's not that bad (also it's been getting better, frozenset was added back in 3.6 and frozendict was finally accepted for 3.15, they're not efficient immutable collection but they're there)
If I remember correctly, Godot started with Lua, and they found it worked well for what they wanted, except they needed it to be more class-oriented. IIRC up until the most recent version of GDscript it didn't even have closures, which always felt like a huge red flag to me. I'm very glad to hear that they're finally allowing other languages than GDscript.
They have always, or for a long time at least, been possible to allow use other languages via dynamic linking. The exact method has varied but the current incarnation of that is what's called "GDExtension".
From a language design POV, GDScript is a poorly designed language. Putting aside the indentation -which is just a preference -, It didn't integrate so far a lot good language design ideas from other languages. It looks just like a lazy copy of python. it is missing so many good things from anywhere else : generics, enums, optionals, etc.
It doesn't mean it is not useful. its integration with the engine is good, the docs are quite complete and you can do a lot with that ugly little language.
But at one point, for any sizeable game, it is the bottleneck for the engine. Yes, you can jump to c++ for that, but the complexity gap is quite large and in a gamedev team, you have less people that can write c++ than people that can script with gdscript.
Yes, you're cherry picking there but even that support my point : gdscript enums are disguised dicts and compared to the state of the art for enums - rust tagged enums AFAICT - they are so far behind.
Even the implementor said that it was a sort of a hack : sketching a feature without not much thought behind it. Pragmatic use of their limited time for sure, but not good language design. Gdscript seems to have been built ignoring 20 years of language design, and while I can understand the limited resources of an open source project, it is frustrating.
hoistbypetard | 20 hours ago
I need to tip my hat to this paragraph:
LesleyLai | a day ago
A lot of the "ugly" part in this article is the same as in Python, which GDScript draws inspiration from.
I think the background is important. The author came from a TypeScript background and also likes to write functional-ish code, so they noticed things people coming from a Python background will probably just take for granted.
Though using GDScript as a "quirky Python", one will also soon realise how underpowered this language is in other aspects.
masklinn | 13 hours ago
Most of them are not in Python at all. Indentations and the callback pain is the only one which is. And Python has shorter anonymous functions but straight gives up on multiple statements in anonymous functions, though named functions have essentially no limitations, they're just more verbose.
Python
mapaCallable[[int], str]onto alist[int]you get anIterator[str](specifically amap[str])technomancy | a day ago
If I remember correctly, Godot started with Lua, and they found it worked well for what they wanted, except they needed it to be more class-oriented. IIRC up until the most recent version of GDscript it didn't even have closures, which always felt like a huge red flag to me. I'm very glad to hear that they're finally allowing other languages than GDscript.
bkhl | a day ago
They have always, or for a long time at least, been possible to allow use other languages via dynamic linking. The exact method has varied but the current incarnation of that is what's called "GDExtension".
LBdN | 12 hours ago
From a language design POV, GDScript is a poorly designed language. Putting aside the indentation -which is just a preference -, It didn't integrate so far a lot good language design ideas from other languages. It looks just like a lazy copy of python. it is missing so many good things from anywhere else : generics, enums, optionals, etc.
It doesn't mean it is not useful. its integration with the engine is good, the docs are quite complete and you can do a lot with that ugly little language.
But at one point, for any sizeable game, it is the bottleneck for the engine. Yes, you can jump to c++ for that, but the complexity gap is quite large and in a gamedev team, you have less people that can write c++ than people that can script with gdscript.
prayerie | 12 hours ago
gdscript has enums
LBdN | 6 hours ago
Yes, you're cherry picking there but even that support my point : gdscript enums are disguised dicts and compared to the state of the art for enums - rust tagged enums AFAICT - they are so far behind. Even the implementor said that it was a sort of a hack : sketching a feature without not much thought behind it. Pragmatic use of their limited time for sure, but not good language design. Gdscript seems to have been built ignoring 20 years of language design, and while I can understand the limited resources of an open source project, it is frustrating.