TwistedTwigleg GDScript is not going anywhere because it offers a superior Godot development experience.

This. It is just too good integrated into the engine. As a scripting language for Godot it is second to none. And C++ is the language when it gets deeper into the engine.

As a Linux user (not Ubuntu), I have no need for .NET. There are superior tools for development in this ecosystem, though they may need some more effort to learn and use. For games as well as systems programming, I'd rather see the upcoming Rust as an alternative. It is in the same performance ballpark as C++ and C, but avoids a whole class of possible programming errors. Though it can drive me nuts with its "You can't do it so I won't let you" attitude :-/.

I believe there are Rust bindings for Godot GDNative, and possibly the new GDExtensions.

TwistedTwigleg there are plans to make it semi-compiled

That would be cool :-)

      Thanks for the insights on the topic, that removes my concerns about GDS becoming obsolete as .NET language supports become fully-functionaly. 😃

      While not strictly necessary perhaps I feel like adding that this doesn't mean that C# support won't continue to improve. There is no need for any 'versus'/adversarial mentality in here. GDScript is developed by people with a dedicated interest in it and C# support is developed by people with a dedicated interest in it. They don't take away from each other.

      Honestly, I think C# will improve mostly because there are new stragglers from Unity, and the fact that Microsoft ported C# to Ubuntu native means the integration is easier. So C# will likely become more popular but GDScript isn't going away.

      This is all strictly opinion, but I suspect that C# will supplant gdscript over time because more godot users will choose it. Ideally they should get equal support, but that doesn't often happen in software projects. The feature with more use will get more feedback and be fixed and improved more quickly. Up to now, most godot users have used gdscript, but C# is more popular in the programming community as a whole.

      A lot of this depends on the health of the godot project -- how many people start using it and who is developing it -- so any prediction is mostly speculation. However, the fact that this question keeps getting asked shows that most people consider language to be a binary choice.

      Since gdscript is mostly based on python, I think new language users will probably choose it. For myself, I like low poly or low resolution games because they are easier to write, so speed isn't hyper critical. I don't mind c#, but I like python/gdscript better. I like that it's all enclosed in the download also. It's good that we have the choice, though. Maybe I would need to get the slight increase in speed, but I doubt it. It's nothing to really worry about because once you know one language, especially one that's kind of c-based, it's easy to learn another. Some people think, oh, I better just choose c#. Programming courses in college generally start out with python. Up till now, godot has made excellent improvements to the language and I think it's just going to get better and faster. Python is no.1 for programming languages in terms of popularity so there will always be places to use it. Not exactly python, but close enough so you can easily use it after a little practice.

        fire7side For myself, I like low poly or low resolution games because they are easier to write, so speed isn't hyper critical.

        Are you running your scripts on the GPU? I'm a bit confused how graphical fidelity relates to the scripting language and script execution speed...

          Of course not. But it is easier to generate and manipulate low poly geometry via the scripting language than more complex things, in which case going to a C++ plugin/tool/extension/whatever would be way.

          Now this could be done with C# (on a scripting level) and it might be a performance win over GDscript, but that's still worlds apart from C++, performance wise I mean and if done right(tm) on both sides, at least excluding brute force. As an example of how scripting language performance can relate to rendering speed.

          It is when we start to generate all or most of the geometry on the GPU and keep it there, that CPU and GPU are more disconnected. But for that approach, Godot is just not the right choice.

          And as said GDscript is better integrated into the engine, thus equally running on any platform Godot runs on, which is not the case with C#.

          Edit: low poly, in my understanding: several thousand triangles.

          My understanding was that the user was making retro games, meaning the overall complexity was less (like PS1 era) not the the geometry had anything to do with the scripting language.

            cybereality Yeah, I just do simpler games. I probably shouldn't have said low poly, although low poly games run faster on older equipment so I don't have to worry about it so I guess I relate the two. I think it's mainly mathematical equations where there is a difference. Anyway, it works fine for my purposes. The low poly for me is because it takes less time to make models, and they take less storage size so I can make an online game, hopefully. I've found some free and I can easily fill in with models I make, or possibly make all the assets for a full game. I might try it later. I hardly ever actually stay on topic, but I'm pretty happy with gdscript and I did try c# for a little bit.

              Is it a possibility that MS could/will buy there way into C# GODOT exclusivity as they did with Unity?
              I like C# and I could switch to it if necessary, but I enjoy GODOT coding with GDScript.
              I hope for continued development of GDScript (as well as improvements to the built in editor).

                I'm not sure how much Microsoft influenced Unity. Unity was using .NET from the beginning, when they were only available on Mac.