> 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.