Godot w/ C# however is very nice and gives you a lot of flexibility with your architecture and code.
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.
How likely would you say the same effort is gonna go into GDScript?
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.
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.
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.
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#.
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?
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.
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.
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.
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.
I don't think Godot should go that route.