[cardanome]

> Does GDScript have good debugging, linting, and profiling tools?

Yes, everything is provided for. No need for separate tools, Godot comes with everything out of the box. (Of course "good" needs to be defined but I personally had no problems.)

> The second form of criticism I've heard is that type issues become a serious problem as the size of game code growns past a certain point.

GDScript has gradual typing support. You get at least TS-level of type safety if you want (but without the headache of TS.)

Also C# is not traditionally a game development language. It has automatic garbage management for which game development happens to be on of the few areas where that is not exactly ideal.

C# is mostly interesting for people already knowing C# or when there are specific performance needs where C# still outperforms GDScript (though personally I would rather write the performance sensitive parts in C++ or Rust).

Most people are highly advised to at least try GDScript. (Also it is very easy to mix and match languages. You can have parts in C#, parts in GDScript, parts in C++, no need to commit early to a specific language.)

[meibo]

> Also C# is not traditionally a game development language. It has automatic garbage management for which game development happens to be on of the few areas where that is not exactly ideal.

Are you forgetting about the now decades worth of games made with Unity? C# works perfectly fine for games, GC behavior can be optimized, it can be transpiled to native code, it has a huge ecosystem and is very easy to pick up. .NET 6 or 7 are faster than ever, while Unity is stuck on an old version of Mono, too.

It's certainly easier for devs coming from C++ or Java than "weird python-like scripting language that we had to invent and are now stuck with".

[cardanome]

Did I say, you can't make games in C#? Why do you feel the need to defend C#? You are arguing against a straw man.

It is simply a fact that a large part of the professional gaming industry uses C++. That one might be better off using a language without automatic garbage collection for performance critical parts in many cases is pretty standard wisdom. Not sure what there is to argue about.

> It's certainly easier for devs coming from C++ or Java than "weird python-like scripting language that we had to invent and are now stuck with".

So you have never used GDScript but feel qualified to have a strong opinion on that matter, why is that?

[meibo]

> So you have never used GDScript but feel qualified to have a strong opinion on that matter, why is that?

I have, which makes me feel confident in stating that it's a language that didn't have to exist, doesn't have a healthy ecosystem backing it, which pulls focus from the actual good (or to be good) bits of Godot, which there are a lot of, and in the end makes people doubt that the language they would actually be productive in is a first class citizen for the engine vendors.

[cardanome]

> I have, which makes me feel confident in stating that it's a language that didn't have to exist

If you have, you should be aware of the history of the project and then I am perplexed why you would make this claim.

They tried using multiple different languages until finally settled for developing GDScript. It is not a decision they just made willy-nilly but something they decided after using different languages did not work out as they hoped it would.

> doesn't have a healthy ecosystem backing

What ecosystem? The ecosystem is Godot and GDScript is an integral part of it.

> in the end makes people doubt that the language they would actually be productive in is a first class citizen for the engine vendors

If you had proper experience with Godot you would know that GDScript is very well liked in the community and people are actually very critical about C# integration, seeing it as more of a distraction and waste of resources. (Of course people that don't like GDScript might simply not stay in the Godot community, so I admit some self selecting bias might be going it.)

The C# integration was only done because Microsoft paid them to do it.

[KronisLV]

> They tried using multiple different languages until finally settled for developing GDScript. It is not a decision they just made willy-nilly but something they decided after using different languages did not work out as they hoped it would.

This is a fair point and it was probably a good fit for their own needs, but I think that the person you're responding to seems to suggest that GDScript and the entire idea behind it basically suffers from NIH - Not Invented Here. So while it may seem like a good idea to them and even many other people out there, they are missing out on a large amount of great tooling (IDEs like Rider or even Visual Studio), lots of development tooling (which they have to write themselves), code style checks, static code analysis tools (I don't think GDScript is supported by SonarQube or has an equivalent to gofmt), as well as a lot of knowledge about design patterns and possibilities of the type systems, which will sometimes feel odd, like Godot's approach to Singletons: https://docs.godotengine.org/en/stable/tutorials/scripting/s...

That's not to say that this will matter for most people - it's likely that for most users it's perfectly sufficient to have a quick and simple language that can have its scripts be edited right there in the editor and is reasonably easy to learn, which is where GDScript shines. Plus, no compile times are really great as well, at least for smaller projects (anyone who has tried compiling large codebases will know how annoying iteration can be in them).

But when you want to hire developers in the industry and take advantage of the existing C#/C++ knowledge, then using either of those and building the whole engine/documentation around them is probably the better choice. If you don't, your efforts might be split a bit thin, e.g. how C# documentation might not be as fleshed out in comparison (a bit like Boo used to be in Unity, which was deprecated eventually), or how C++ might be way lower level (which Unreal Engine also suffers from, because of which they offer their Blueprints system).

> What ecosystem? The ecosystem is Godot and GDScript is an integral part of it.

With time, Godot will probably have lots of possibilities around game development related topics, albeit in a focused manner - there was a terrain plugin written in GDScript, some efforts to get dynamic rendering scales up and running, probably some game logic related stuff and libraries for working with splines and whatnot. That said, many of these will feel a bit barebones and underdeveloped, because Godot doesn't have a large (or any) paid assets scene, which in turn means that the majority of packages will be volunteer efforts, for example: https://godotengine.org/asset-library/asset/231

That said, GDScript absolutely does not have a large ecosystem around general purpose computing tasks. Suppose I want a file server embedded in my multiplayer game, to allow users to fetch asset packages dynamically, like Half Life community server maps, which might turn out a bit difficult with GDScript. Similarly, if I want a WebSocket connection to subscribe my game to announcements from a central server, that might be difficult to get working. Similarly, if I want gRPC calls or to consume messages from RabbitMQ, there might also be no support from that. Talking among multiple other peer servers with PKIX or JWT? Probably not too easy to do. OAuth2 flows or something like OIDC? Connecting to a database from a server, to fetch player profiles? Nope, still need an additional separate API app that will talk through a RESTful API that GDScript might allow me to consume - even when I know that I will only be running the servers myself and don't need to think about the n-tier architecture. Of course, I think there were attempts at getting SQLite support working, which was pretty cool!

Of course, most of what's mentioned are just ideas around larger projects that might need some sort of a networking implementation, but the same might apply to image processing, audio processing, parsing data formats etc. That's not to say that Godot won't get around to at least some of those eventually, but in the case of C# and .NET/Mono in general, it might just mean pulling a NuGet package and reusing some of your old code from Unity/Stride projects (at least the non game engine specific parts).

That's not relevant for like 98% of the games out there like single player platformers, shooters etc., but you'd be surprised about how many cool ideas people have around general purpose computing in games!

> If you had proper experience with Godot you would know that GDScript is very well liked in the community and people are actually very critical about C# integration, seeing it as more of a distraction and waste of resources.

This is definitely a pain point and an issue that will cause division - since most game engines won't fare too well supporting multiple languages, especially if already spread thin without the support of a million/billion dollar org behind it all.

That said, you can hire C# developers and C# game developers, with experience in other engines. In that regard, GDScript might be a tough sell. The current community doesn't care much about that, or the things I've mentioned before, because they're largely hobbyists who generally develop games due to their own passion, instead of what a Gantt chart says. Thus, there might be a bit of a self-selection going on.

Either way, here's hoping that Godot will have a bright future ahead of it, currently still considering using it over Unity due to its open nature, albeit primarily using C# with engine agnostic code libraries. I do hope that C# support doesn't fizzle out, because personally I find it to be a pretty great language with a nice ecosystem around it.

[cardanome]

> But when you want to hire developers in the industry and take advantage of the existing C#/C++ knowledge, then using either of those and building the whole engine/documentation around them is probably the better choice.

Programming in C++ is well supported though. This is the main reason I personally would not use C# in Godot much. It is really good general purpose language that will do fine in almost any situation but it will not excel as much on performance critical stuff like C++ does but also does not have the ease of use for quick scripting like GDScript.

I guess it is a matter of the philosophies. Some people really like to use just a single language and then C# is a excellent choice while I think having languages optimized for certain strengths might be a good idea. So for me it is GDScript + C++/Rust/Nim if need be (the later ones also providing some safety on top of performance). Plus the vast majority of hobbyist devs will never run into any limitation with GDScript to begin with.

> That said, GDScript absolutely does not have a large ecosystem around general purpose computing tasks.

You have the whole C/C++ ecosystem of libraries that you can use if need be. Maybe not from GDScript directly but from a GDExtension language binding of your choice. If you are at the point that you can even dare to think about complex multiplayer games, you are a professional and can be safely expected to know how to use C/C++ libraries, mostly.

Though the ecosystem C# brings additionally to the table is also very nice to have, that much I admit.

> That said, you can hire C# developers and C# game developers

Can you, though? Writing a CRUD app in C# is quiete different to writing C# in Unity which is different to C# in Godot.

Maybe I am biased because I enjoy learning programming language but I am genuinely confused about the practice of hiring for specific languages. Maybe there are some developers that refuse to learn anything new, having been much on the other side.

Learning a new language takes days or worst case a week, learning libraries, best practices, switching towards a whole new area like game dev vs backend dev, that takes lots and lots of time. You can't really take a Unity dev and have them be productive in Godot from day one, they still need to learn how the engine works, how it expects them to structure their code and so on.

Anyone that has worked with a scripting language before can learn GDScript in a few hours, that is not a blocker at all. Wrapping you head around nodes and all on the other hand takes some time.

I think hiring for general game dev experience works out much better, as the concepts translate through languages and specific engines.

> Either way, here's hoping that Godot will have a bright future ahead of it, currently still considering using it over Unity due to its open nature, albeit primarily using C# with engine agnostic code libraries. I do hope that C# support doesn't fizzle out, because personally I find it to be a pretty great language with a nice ecosystem around it.

I think they are quiete committed to it at this point. There is obviously vast outside interest in it from all the people coming from Unity. Plus Microsoft has obviously an interest to keep C# in Godot and so will probably keep the money flowing.

That said Godot is not ready for complex 3d games yet with or without C#. It is still far away from Unity. Godot 4 did make big steps but I would expect that will take at least until 4.1 for it to be ready for bigger professional projects. For 2d though it might be best in class and superior to Unity.

[Mikeb85]

> It's certainly easier for devs coming from C++ or Java than "weird python-like scripting language that we had to invent and are now stuck with".

??? You can do everything in Godot in C++...

And GDScript isn't exactly a 'weird' language, it's downright ordinary in terms of semantics and features. The feature is that it's part of the engine and maps directly to C++ methods in the game engine...

[handsaway]

GDScript is fine and I use it but it's a stretch to compare its type system to TypeScript. GDScript doesn't have generics let alone conditional types, string template types, variadic tuple types, etc. TS is significantly more sound as well if you turn on a lot of the strictness options.

[throwaway675309]

Between XNA, monogame, Unity, etc. there a metric f###-ton of games written using the C# language.