Hi and welcome! These questions look like they would probably better fit the users’ forum over on users.rust-lang.org. Feel free to re-post there if you want more people to see your post and be able to provide answers.
I’ll already give some short answer your questions here quickly, anyways
Rust is free and open source software. You can see some general information about the precise open source licenses being used e.g. here and here. As free and open soft software, you are not only allowed to use the programming language, its compiler and other official tools for free, but you can also inspect their source code, or even re-distribute them in original or modified form. (See the licenses for the minor conditions that apply for re-distribution.)
Rust is independent of C++ compilers in general, but uses LLVM, which is the same compilation infrastructure that clang uses. The perceived usage of “Microsoft visual c++ compiler” might be due to the Windows installation procedure, which (if I recall correctly… note I haven’t used Windows in a while) recommend usage of the linker that comes with the Visual C++ tooling. As far as I’m aware, it should be possible to use other linkers, but don’t ask me how, and I believe I heard that possible downsides might include reduced inter-operability with system libraries or other 3rd-party C libraries, but don’t quote me on that
There’s a few of “are we … yet” websites tracking the status of certain types of libaries / frameworks existing for Rust. https://www.areweguiyet.com/ is the one for GUIs. I’m myself not experienced with any GUI application development using Rust, so maybe others can add more information. As far as I understand the status quo, there’s still room for improvement regarding GUI libraries; I suppose GUI libraries, especially very general, very useful, well-designed and multi-platform ones, aren’t an easy thing to build and maintain.
I searched for existing explanations, as I cannot try anything on Windows myself. I found this discussion which also linked to this page and it looks like in order not to need the linker for “Microsoft Visual C++”, you’ll need to switch away from the corresponding -msvc targets and using the -gnu one instead. What exact commands you want for this is a bit tricky / depends on what exactly you want to do, and is roughly described in this comment in the linked discussion. Apparently you can change the meaning of short identifiers like stable or nightly toolchain names by changing the “default-host” setting, e.g. via rustup set default-host x86_64-pc-windows-gnu. You might then (or before that) also still need to install the relevant toolchain, e.g. rustup toolchain install stable-gnu , and making it the defaut is yet another command, like rustup default stable-gnu. Though after changing default-host, I presume (no way to test it myself now) that these could then also be written simply rustup toolchain install stable and rustup default stable. If you already had the msvc toolchain installed, you can also uninstall that if you like to; feel free to navigate through rustup help or rustup some…command… help yourself to figure that out.
The previously mentioned downsides are formulated on the linked rustup book page as follows
Since the MSVC ABI provides the best interoperation with other Windows software it is recommended for most purposes.
But I don’t personally know the precise/specific implications of what kind of “interoperation with other Windows software” you might be sacrificing.
If you use the x86_64-pc-windows-gnu toolchain, then it's independent of Visual Studio; if you switch away from Microsoft Windows, then you can use Rust without any ties to Microsoft at all.
The MSVC toolchain will produce smaller binaries, since the MSVC C Runtime and C++ Runtime are provided with Windows. It's also ABI-compatible with the MSVC C and C++ compilers, in as far as that applies, whereas the GNU toolchain uses a different unwinding mechanism; this only matters in cases where you're interoperating with DLLs other than those shipped with Windows.
The GNU toolchain isn't tied to Microsoft at all, and avoids the need to pay Microsoft licensing fees for Visual Studio and the MSVC toolchain.