[droptablemain]

I know Godot team is very committed to GDScript, but I find it hard to see it as anything but a toy scripting language. Seems like it would be a real mess with a big, complicated project.

Godot w/ C# however is very nice and gives you a lot of flexibility with your architecture and code.

[gustavus]

> but I find it hard to see it as anything but a toy scripting language. Seems like it would be a real mess with a big,

We are talking about GDScript not JavaScript.... Oh wait, the parallels are remarkable

Simple language designed to be easy to learn: Check

Turns large codebases into a tangled lovecraftian mess of spaghetti code: Check

Likely to be someone's first introduction to programming languages: Check

Honestly reading the criticisms of GDScript so far is convincing me more and more that Godot is quickly going to become the next big thing, especially if the developers can figure out how to get people to use it for thier first programming project. After all most people I know who got into development started because they wanted to make their own video game.

[eddythompson80]

As others have mentioned, JavaScript also has had over 20 years of serious investment from the best minds in the industry to improve it. We now have V8, TypeScript and plethora of tools that make writing serious applications possible or even preferable. I seriously would take TypeScript over most languages any day.

How likely would you say the same effort is gonna go into GDScript?

[johnnyanmac]

>How likely would you say the same effort is gonna go into GDScript?

Hard to predict. We're still in the web 1.0 phase of Godot and dealing with questions like why we made a <blink> tag. We could get serious talent addressing the binding layers, we could simply have a few key bottlenecks addressed, or we accept GDScript as the slow path and diverge. It could also simply fade away, but many don't want that, and I'm also not too interested in deprecating something many have used to launch full games.

Personally, my goal is less about making a scripting language perform as well as c++ and more about having options to make sure people can port from GDScript to some faster binding if/when they run into performance bottlenecks. At worst, maybe a migration tool may be needed. Hard, but more doable than any of the above overhauls.

[gustavus]

Well that's a point a lot of other people have raised and is the one I am trying to make, Godot and the associated ecosystem could become like the next generations Javascript. Companies didn't start investing an enormous amount of time and effort into improving JS because they wanted to, they did it because they adopted it and then ran into cases where they needed the performance.

My point being that a lot of the concerns are not foundational to Godot and GDScript and can be improved if there is an investment. But that investment will come with adoption, not the other way around.

[krapp]

Javascript only got the investment it did because it was the only language that would run in a web browser, when the web suddenly became a billion dollar business and javascript developers were a dime a dozen. Godot is able to support multiple languages. The goal should be improving and expanding language support, not repeating the necessary evil of making Javascript the One True Programming Language.

[headcanon]

I too found it a bit cumbersome past a certain code size. A lot of games don't necessarily need a lot of raw or complex code to run though, so the 1st class benefits of GDScript start to shine, like the native debugger, autocomplete, Godot-specific accessor syntactic sugar.

Its hard to compete with an almost 25 year old battle-tested language, but given the domain and the team size, its a good product and worth pursuing IMO. With that said, I wouldn't want to give up the ability to have C# interop when I need it, and I imagine many games would need to be rewritten in C# after a certain point.

[dandellion]

It's probably not ideal for large projects, but it adds huge value for small ones, and for people who are learning, and I'd expect probably even in larger projects if combined with C++, C# or Rust. It's miles better than the joke Unity had that was called Boo. I also like it a lot better than Blueprints in Unreal while still remaining extremely simple, although I can see how Blueprints can be better for more visual people.

[janosdebugs]

I concur. I believe GDScript should be split from Godot itself and support should be added for third party IDEs. It has a lot of hard-coded things specific to Godot in it and it suffers from it. The built-in code editor has a very confusing layout and its built-in code editing functions will never be as powerful as providing a language server to a dedicated IDE.

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

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

[Lucasoato]

They should remember that even Unity had to deprecate the Boo language to go forward :)

[dandellion]

Not sure Unity is a good role model...

Also, having used both Boo back in the day and GDScript in Godot more recently, I'd say that one big difference between the two is that Boo was really bad, and GDScript is actually pretty good.

[eddythompson80]

What's wrong with Unity from a technical prospective not marketing/business prospective?

[johnnyanmac]

Unity got a stigma for delivering half baked features and dropping support for existing features without a replacement. The epitome of this was where in Netcode, where I believe they had no officially supported solution despite the engine having 2 different packages which were both half-baked, all while the DOTS variant was far from release.

I don't think Godot should go that route.

[cfgyuiikhg]

It was fat and glitchy from the get go.

[mattigames]

Both Boo language and UnityScript were deprecated (the later was oftenly mislabeled as JavaScript, creating quite a confusion between newbies)