The GDScript hate is so odd.
If you know any scripting language you know GDScript. How much time are you wasting when it takes one afternoon to learn? And nowadays it even has gradual typing support for those that are scared of dynamic types.
I have seen C# devs coming to Godot being super prejudiced against GDScript and then end up using GDScript anyway because it is just more pleasant to use.
Mostly because I don't like the Python-style use of significant whitespace. But functions aren't first class citizens, making closures and lambdas awkward, type hinting isn't supported everywhere (such as with callables). I could probably come up with more petty gripes if I opened up a project and played with it. "pass" is an abomination to God.
It's a lot better than it used to be and it gets the job done but I still find it ugly and awkward as a language.
A more general complaint I have is that Godot tries to load every script regardless of whether it's actually included in the game hierarchy.
If you aren't scared of dynamic types for any type of semi-large project (like a game..) then you aren't qualified to talk about much.
Like "schemaless" database applications, there's always types/schema somewhere: the choice is if they'll be explicitly defined at the place of construction, or implicitly spread out across all the places data happens to flow in your application. And the more places there are, the more spread out they'll be.
Static typing is also really nice for game dev since proper unit tests are harder (but not impossible) compared to your average CRUD app.
The discussion is exhausting because many people don't understand the difference between weak typing and dynamic typing. You basically never want weak typing but dynamic typing has legit uses. Yes JS is both weakly and dynamically typed and that sucks but Common Lisp shows you can have very strong typing and dynamic types.
Lots of very complex software has been writing in dynamically typed languages. The whole Erlang/Elixir world is dynamically typed though Elixir is getting gradual typing.
There is a good reason gradual typing is getting popular, you get the best of both world. You can prototype quickly and then add types and make everything more solid later.
(Which also why you want to always use a statically typed language in the corporate world because there is never a "later" and the bigger the team the more important it is to have the lang enforcing discipline. But not every programming is corporate.)
People that are dogmatic about static typing show their immaturity. The older I get the more I realize that there is no right or wrong way to program, everything it tradeoffs and "it depends".
You literally start your comment by reaffirming my point (prototyping, like when you tend to have a smaller code base?)
Feels like you replied to a comment you imagined based on past interactions, not anything I actually wrote.
I never said that any part of your comment is dogmatic. This is not private conversation where I am talking to you directly.
I wrote
> People that are dogmatic about static typing show their immaturity
Referring to the people like eatsyourtacos who started this discussion.
Why?
> And the more places there are, the more spread out they'll be.
I think there are many other factors that come into play when it comes to maintaniblity of large projects. I'd easily choose to maintain a large Elixir or Common Lisp codebase over a Java one, assuming they were all using the Best Practices™ of their respective languages.
There is research out there, and there is absolutely zero evidence that static typing catches more bugs than dynamic types. My experience is that immutability, functional programming, simplicity and testing pays a MUCH bigger role in maintainability than static typing.
Dynamic typing has trade-offs, and so does static typing, HUGE trade-offs by the way. But for some reason, no one seems to mention them... ever.
If I need to specify this is about data flow inside your application when we're talking about typing, I don't want think we're having the same conversation.
Hopefully someone else will want to mud wrestle on this.
The other things are that it just has less support for structuring your code in different ways, and of course the performance is vastly worse. My game does some state space exploration for the enemy AI, so having code that runs an order of magnitude slower just doesn't work for me.
As for performance well the GDExtension support has also gotten much better. You can always go down to C++, Rust, Nim, Zig or whatever. It is really easy to set up.
You can also use other garbage collected languages. I once tried the Lua bindings and they worked fine.
The problem with C# is that its garbadge collection is not really suited for game dev. The creator of the Mono runtime actually calls using C# his Multi-million dollar mistake and instead works on swift bindings for Godot: https://www.youtube.com/watch?v=tzt36EGKEZo
But if you really love C# nothing is stopping you. I prefer GDScript.
Swift might be cool too, I've only used it a bit but I liked what I saw.
(yeah there are escape hatches, but it's weird to use them)
So when people come out and defend gdscript for being not that bad, it's like, okay, but it's still really shitty compared to any normal language like C# or even Python. It is made by a game engine, used by thousands of people, instead of being made by gorillions of dollars poured into it by tech companies and used by millions of people. I'm just going to use good languages instead.
GDScript might be a bad general purpose language but it is a good language for Godot.
You say Python is a "normal" language for me while I love Python, modern Python has gotten way too complicated and clunky with lots of new features added. For me GDScript feels much closer to the original pythonic ideal. Plus it is much easier to learn for people that are not professional programmers.
Maybe you don't enjoy using GDScript and that is fine but saying it is a "objectively bad" language is really uncalled for. For many devs it is the right fit.
C# and GDScript are no different. They both have made design decisions for particular reasons.
You’re a skilled developer in real languages, so I’d encourage you to explore why other developers might prefer a DSL for their needs!