> 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.
This is an excellent point, though it also brings the complexity of C++ as a language to light as well. That's why many use Blueprints in Unreal Engine, just so they wouldn't deal with a powerful language like C++ that has lots of footguns, despite its libraries, interop and other capabilities. So much so, that they tried getting C# support into the engine (as well as a few others over the years).
In a sense, it's a spectrum, with something like C++ on one end, C# somewhere in the middle (reasonably performant and capable, but also with relatively few footguns) and GDScript on the other end, even though the library support isn't as good as, say, Python. Hence, if you need bunches of fancy functionality, you'll probably need to choose between either C++ or C#, not having access to the latter complicating things.
> Can you, though? Writing a CRUD app in C# is quite different to writing C# in Unity which is different to C# in Godot.
The concerns are a bit different, especially when you're racing against the render loop, but I'd argue that it's not all that dissimilar, be it in regards to C# in specific engines or different types of applications.
Personally, with a few key differences in mind, there isn't that much difference between developing local CRUD apps, doing web development, or even game development - those key differences in the case of game development being more focus on linear algebra and performance, and utilizing other abstractions (for example the whole scene graph concept and traversing it, which honestly is not that dissimilar from something like Pinia stores, which might be an interesting comparison).
Between different engines, you have the whole component system of Unity, which I think is a better fit for my personal headspace, but then again having everything be nodes in Godot is also great, especially since dealing with prefabs is no longer quite as awkward, even though you cannot attach multiple scripts to a single node, which is inconvenient.
In comparison, writing any kind of piece of software in Rust would be a wildly different experience from doing the same in C#, due to how different the language concepts (e.g. borrow checker) are. Similarly, I'd personally say the same about C++ and C# (the whole approach to memory management, even with smart pointers) and C# and GDScript (the gradual typing in particular).
> 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.
I'd suggest that learning a new language can take anywhere from a few months to close to multiple years, depending on the language and what you intend to do in it, especially when coupled with particular stacks/frameworks/engines. Just look at how much C++ software there is out there and how much of it is full of memory management related bugs. Sure, you might knock something together after a weekend with a book or two, but getting to truly know the ins and outs of a language, as well as some of the more popular design patterns (at least in the context of that language) will probably take way more than a week.
I do fully agree with your points about different engines having plenty of specifics, but would like to offer the suggestion that transferring from C# in Unity to C# in Godot will be a comparatively easy process, versus learning GDScript and not being able to use any of your in house non game engine specific libraries for development. Something like maths for splines, some back end logic for handling inventories, levelling up, dialogue trees, quest systems etc. Of course, in practice many end up being tied to a particular engine because nobody cares about portability - much like ORMs in practice rarely allow for painfree migration across different DBs.
> That said Godot is not ready for complex 3d games yet with or without C#.
With this, I can agree. It's nice to think about the future of the game engine, though. Somehow Godot seems to have gotten way more traction than the likes of Stride (which was great), NeoAxis, or even something like jMonkeyEngine. Not sure what their magic sauce was, but I hope they have a bright future ahead of them.
This is an excellent point, though it also brings the complexity of C++ as a language to light as well. That's why many use Blueprints in Unreal Engine, just so they wouldn't deal with a powerful language like C++ that has lots of footguns, despite its libraries, interop and other capabilities. So much so, that they tried getting C# support into the engine (as well as a few others over the years).
In a sense, it's a spectrum, with something like C++ on one end, C# somewhere in the middle (reasonably performant and capable, but also with relatively few footguns) and GDScript on the other end, even though the library support isn't as good as, say, Python. Hence, if you need bunches of fancy functionality, you'll probably need to choose between either C++ or C#, not having access to the latter complicating things.
> Can you, though? Writing a CRUD app in C# is quite different to writing C# in Unity which is different to C# in Godot.
The concerns are a bit different, especially when you're racing against the render loop, but I'd argue that it's not all that dissimilar, be it in regards to C# in specific engines or different types of applications.
Personally, with a few key differences in mind, there isn't that much difference between developing local CRUD apps, doing web development, or even game development - those key differences in the case of game development being more focus on linear algebra and performance, and utilizing other abstractions (for example the whole scene graph concept and traversing it, which honestly is not that dissimilar from something like Pinia stores, which might be an interesting comparison).
Between different engines, you have the whole component system of Unity, which I think is a better fit for my personal headspace, but then again having everything be nodes in Godot is also great, especially since dealing with prefabs is no longer quite as awkward, even though you cannot attach multiple scripts to a single node, which is inconvenient.
In comparison, writing any kind of piece of software in Rust would be a wildly different experience from doing the same in C#, due to how different the language concepts (e.g. borrow checker) are. Similarly, I'd personally say the same about C++ and C# (the whole approach to memory management, even with smart pointers) and C# and GDScript (the gradual typing in particular).
> 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.
I'd suggest that learning a new language can take anywhere from a few months to close to multiple years, depending on the language and what you intend to do in it, especially when coupled with particular stacks/frameworks/engines. Just look at how much C++ software there is out there and how much of it is full of memory management related bugs. Sure, you might knock something together after a weekend with a book or two, but getting to truly know the ins and outs of a language, as well as some of the more popular design patterns (at least in the context of that language) will probably take way more than a week.
I do fully agree with your points about different engines having plenty of specifics, but would like to offer the suggestion that transferring from C# in Unity to C# in Godot will be a comparatively easy process, versus learning GDScript and not being able to use any of your in house non game engine specific libraries for development. Something like maths for splines, some back end logic for handling inventories, levelling up, dialogue trees, quest systems etc. Of course, in practice many end up being tied to a particular engine because nobody cares about portability - much like ORMs in practice rarely allow for painfree migration across different DBs.
> That said Godot is not ready for complex 3d games yet with or without C#.
With this, I can agree. It's nice to think about the future of the game engine, though. Somehow Godot seems to have gotten way more traction than the likes of Stride (which was great), NeoAxis, or even something like jMonkeyEngine. Not sure what their magic sauce was, but I hope they have a bright future ahead of them.