I suggest sticking with GDScript for Godot, you’ll find a lot less friction, it’s a lot easier for a beginner, and most of the learning material is based on GDScript.
It’s a great idea to learn other languages, but I would recommend applying to their intended contexts. If you really want to learn C# then perhaps consider getting into DOTNET, if you want to learn the ubiquitous JavaScript then get into web dev - you may find the learning experience a bit smoother.
Also perhaps consider doing something like Harvard CS50, where you can really get to grips with programming fundamentals - working with a language like C will really make you appreciate the simpler and more concise nature of dynamic languages.
It depends on how you learn best. A more difficult language can prepare the beginner well, but you may find the complexity off-putting, whereas a simpler language can be a really good way to get started and see immediate results, but might not prepare you as well for dealing with more difficult concepts such as OOP and types etc. There is no right answer just give it a, see what works for you - and have fun!
C++ is a low level language, most programs are made with it, godot included. knowing C++ can allow you to contribute to godot with new features, bug fixes and improvements. But it is also considered the most difficult (I still find C# harder due to having more stuff).
as for making a game, C++ can do everything gdscript does, in fact the editor is made using godot with C++.
in godot everything is an object, and a script just extends a node’s class and provides an easy way to interact with the editor: you end up with a new node with new features. the same can be achieved with C++, it would just take longer because you need to debug it, compile it multiple times, and linking uses a lot of memory. using gdscript is just better because it’s significantly faster.
but a game written in gdscript could be ported to C++ to improve performance.
all of the nodes provided by godot are coded in C++, they are just as generic as possible to allow the user to control what they want to do and make more complex things by combining and extending them.
I never said or implied that C++ cannot do what GDScript does. However, the fact that it can do that does not mean it should be used for that. Porting a game to C++ will not necessarily improve performance (at least not by as much as one might expect) if you are unaware of the inner workings and best practices of the language and if the compiler you are using is not very good at optimizing (for example, MSVC is infamous for producing rather poor results, even with optimizations on [although it is by far the best compiler in terms of feature support]). In other words, my original point stands; it’s better to not bother with C++ (or at least with programming a whole game in C++) unless you explicitly want to change Godot’s internals. If you want increased performance, isolate the part of the code that needs this performance increase and implement it using GDExtension instead.
Not to mention that C++ doesn’t really have “less stuff” than C#. If anything, it’s infamous for how ridiculously complex it is. C++'s standard itself is nearly 2000 pages long. “Nobody really knows C++” is a quote I have heard somewhere and I really like, because it reflects how ridiculously messy the language is (this shouldn’t be confused with me saying I do not like it; I, in fact, do like it). C++ should also not be confused as a simple extension over C (it’s not just a “C with classes”), since it has shifted from this philosophy ever since C++11. Nowadays, coding C++ in a “C with classes” style is rather frowned upon. To put all this under another perspective, there’s an actual reason why Rust has been the “recommended C++ alternative” the last couple of years, the complexity needed to get a C++ program right being it.
Also, C++ is not really considered a low level language nor can it really be claimed that most programs are made with it. It’s a rather high level language, especially if you consider the features versions after C++11 have introduced and how much abstraction over hardware the STL offers (which most seasoned C++ programmers highly recommend that you integrate in your C++ programs).