Idiomatic C# is PascalCase public members. Look at the BCL. Yes, the capitalization of fields in Unity determines the flavor of property, buy that's exactly what attributes were designed to do.
> GDScript is a language built for game engine scripting. It has deep knowledge of game concepts, as well as the scene graph.
Agreed, however it also being purpose built not only makes it so that your skills will be non transferable, but also that learning resources for it will be more limited in comparison as will code libraries.
For example, last i checked the language also has some interesting restrictions, like no Singleton design pattern for example; that alone makes managing global background services in games harder. Edit: seems like you can sort of have Singletons now, though having some that are completely separate from the scene graph would be even better: https://docs.godotengine.org/en/stable/getting_started/step_...
There are some really lovely people making plugins for Godot as we speak (the terrain one is especially cool), however it will take years for an ecosystem to be built around Godot. Historically, it has worked out for some languages nicely, like Lua, but less so for others, like ActionScript. For some people a purpose built language is a boon, for others it's a drawback.
> There is a GD build with first-class C#
I think our definitions of "first class" differ. In Unity, you don't use anything else apart from C# and even when there also was Boo or their version of ECMAScript, C# got a really large amount of love in regards to documentation, examples and tutorials.
Since C# support is so new in Godot, that's not exactly the case and for example, as of now i cannot yet open a project in JetBrains Rider and get information about which API methods are slow and should be used with caution, or common code suggestions like i can for Unity.
Now, personally i believe that C# being supported is a good thing and even Godot having separate builds for versions with/without is an idea that makes sense, but there's still a lot of refinement to be had before it is truly usable enough so that you can breeze through projects with it and be sure that both your code will be performant enough (without having to go down to a lower level) and that you won't hit snags along the way.
The efforts of Unity to have their .NET workflow be smooth and comfortable cannot be praised enough - if they gave as much attention and consideration to the actual editor and plugin ecosystem (as opposed to deprecating features with no replacement, or releasing features before they're stable), they'd really be in a stable spot!
Oh, and you can also look at Xenko/Stride engine to see what another engine that uses C# and has had a bit more attention given to it looks like (even though the engine itself is somewhat half baked and doesn't have terrain support out of the box, much like Godot).
That said, i'm sure that the situation will only improve in the coming years!
But you need to remember that it's only been three years since you could use the latest C# version in Unity. Before that change you were stuck with an absymally old NET runtime (Mono from 2011) that only supported C# 3 (with a few C# 4/5 features), and had an incredibly bad garbage collector (Boehm stop-the-world GC) that would cause lots of headaches. Lots of good stuff like LINQ was discouraged in Unity because of the GC issues, and Unity C# was quite different from "normal" C# (with all its hacks and workarounds). The ancient Mono runtime was all because of licensing issues with Novell/Xamarin (Novell developed the Mono runtime until it got bought by Xamarin) - Xamarin probably asked for an enormous sum for the relicensing, and Unity refused it, resulting in Unity unable to update Mono for 6 years.
If Microsoft hadn't bought Xamarin and rereleased Mono with a more permissive license than AGPL (so that Unity can finally update their Mono runtime), then Unity would have really met its downfall. If this (stealth) partnership between Microsoft and Unity didn't happen, I expect a lot of developers to have already moved on to Unreal/Godot in much faster rates.
GDScript is good enough for what it does, especially as an introductory language for people who have not done game development before.
Personally I found that the choice of programming language mattered much less than I thought they would, since I spent most of my time and effort on drawing rather than coding.
I've been doing C# since .Net 1.0, have netcore contributions, and have to conclude that this is "pro" extremely subjective.
- Unity forces you to use ugly non-idiomatic C#.
- GScript is a language built for game engine scripting. It has deep knowledge of game concepts, as well as the scene graph.
- Rust/other via GDNative are just as good as DOTS.
- There is a GD build with first-class C#.