at work you'll probably use something like jira, github projects or taiga so it's good to learn using and relying on a single source of truth designed specifically to see who's working on what and keeping the specs in one place. Also this one is a disputable, but I think that compared to e-mails, IM apps feel slightly more hostile towards the right to disconnect (read receipts and activity status for example). Also in professional env if a company cares about it's trade secrets it will not rely on 3rd party solutions for all of it's communications.
I'm old enough to remember years of people complaining about overzealousness in closing threads as duplicate on forums, even when the issue might have been somewhat specific but the user could have just been unable to correctly recognize all factors at play with their issue (things like firewall, dependency versions and their configuration, environmental variables, hardware etc.) or the issue was actually caused by new bugs or API/ABI changes.
But at least there was some redundancy reduction and things were usually well categorized and tagged and many places actually implemented some pretty decent fuzzy search for similar existing issues. Instead we've ended up in both users and maintainers really wasting their time on something already resolved much more often.
If you don't have time/are too stubborn for that, good luck skimming through tutorials to extract the info you need and pasting/adapting others' code all while hoping there were no breaking changes since the snippets you want to use were published. At which point you might as well go ahead and browse type definitions and function signatures if you're lucky to use something written in a self-documenting style.
Rust's memory safety is much different (ownership, lifetimes, immutability). Also Rust has null safety while Go doesn't. Go has some uninitialized variable use protection, but you can still screw up if you do stuff like accessing a struct field that hasn't been assigned a value. In C there's much higher chance of segfaults, use-after-free precisely due to manual memory management (malloc and free, which do not exist in Go). For example earlier versions of Java and most interpreted languages of the past whilst offering memory safety, consumed a lot of system resources, making them unsuitable for performance critical things like games, drivers etc.
Then innovations in memory management and the resulting safety improvements and easier development these new languages offer allowed using them for writing performance critical code. Hope that answers your question.
I think it's reasonable if the users are given the ability to fill in bug reports via discord and then that gets forwarded to a git forge via some bot so that they don't have to deal with setting up an account on said forge. But if discord is the primary tool for such tasks then it's kinda messy, like trying to idk, replace pliers with scissors, or trying to use a ruler to cut things. Technically you can and it might work, but we created specialized tools for various tasks for a reason, why try to make the tools we use like jacks of all trades and masters of none?
Tbh for some people there's no going back once you learn it. Navigating a GUI and clicking through several buttons vs having a nice shell with completions and whatnot like Fish and learning piping at some point just becomes faster, same thing as using modal editors.
virtually any built in card works these days. with 3rd party cards... well you're better of looking up it's chipset and how well it is supported by linux before you buy one, for example some cheap realtek dongles had no WPA3 support and worse throughput. Iirc Broadcom has for a long time been hostile towards linux.