I don't think it's a good idea, but I think it'd be a fun one, which is why I offered to work on it. I make enough at my job (not dev, but it does include a shit-ton of scripting) that money isn't much of a motivator. If your primary goal with this is to recruit people, I'm not interested.

I'll bite. Though I think this is a hilariously unnecessary idea, I also think it'd be kinda fun. I don't need/want your money.

I recommend you be wary about VirusTotal results. If you really have a novel sample (which is unlikely, but hey, it's possible), it's likely that very few vendors will detect it. This doesn't mean the file is clean. An antivirus detection is simply a detection: it means that files are detected as malware, not that they are or aren't malware. Certain detections, such as McAfee's "Artemis" and Symantec's "Reputation" are utter fucking garbage.

Keep in mind that vendors can only update their signatures once they know a piece of malware exists. Most if not all of the vendors listed on VT are able to receive new files to perform processing on, as well as quite a few other parties. So upload your file to VT, but take the results with a grain of salt until you upload again a couple days later (at which point you can trigger a rescan).

"Ease-of-use" devices, snapshots, and networking are the three biggest things to worry about, in my opinion, though I wouldn't know about anyone forgetting about them. These are honestly just rules of thumb. I break all of them, but you probably shouldn't unless you have a very good idea of the consequences, as you have to take other, more convoluted precautions (which I'm not going over).

1. Virtualbox and VMware both install virtual devices on your host, that allow a limited direct communication, copy/paste, and file transfer. This is only an issue if you install VMware Tools (or whatever the Virtualbox equivalent is--I don't remember what it's called). So, don't install it in the VM.
2. Make sure to take a snapshot (which is like a fixed record of your exact VM in-time) after you have your tools set up on your VM, and before you run your malware. After you've finished detonating it, revert your snapshot.
3. After you download the malware, disable either the network device on the outside or from the settings panel in whatever program you're using.

Qubes is a Linux distribution that runs every program in its own, Docker like, container. That's not a VM; it's an OS. It can't run Windows programs without Wine, and I'm not sure how secure Wine is on Qubes. I've looked at Qubes before, but I've never seen any formal inquiry into the claims it makes about its security features.

Virtualbox and VMware allow you to run whole operating systems in their own container. While these can be insecure if improperly configured, they're probably secure if they are (I say probably, because lord knows some government agency has some VM-breaking exploit, but that's not really an issue here), and considered safe for general use. The most secure way to run malware (only relevant for really nasty APTs like the next Stuxnet or something) is probably Bochs, which emulates the hardware rather than using CPU virtualization functionality, but that's slow.

I analyze malware professionally. The fact that it got past Gmail's spam filter doesn't mean much. While I'm not really interested in analyzing your sample (I have access to pretty much all of the fun malware I could possibly want, and this is probably just a banking trojan), I can make a few recommendations for free tools that are usable by a beginner. Obviously, you should only run malware in VMs (I prefer VMware Workstation/Fusion, personally), so keep that in mind if you do decide to look at the thing yourself; you should probably download directly into the VM, in case an exploit kit such as Angler is being used.

• ProcMon (from Sysinternals) and Process Hacker are good for very top-level dynamic analysis. I recommend using ProcMon with Noriben, which filters out the crap. I prefer API Monitor to ProcMon, honestly, but it'll give you even more useless crap than ProcMon if you don't know what you're doing.
• ExeinfoPE is decent for static analysis.
• Sandboxie with BSA (Buster Sandbox Analyzer) is killer for sandbox-in-a-VM analysis when you don't want to resort to something like Cuckoo.

All of these tools are relatively easy to use. Google is your friend here, but if you have specific questions, feel free to ask in response or a PM.

What kind of applications have you used Go for?

Web server middleware.

The type system is not as rigid as C/C++

I think Go's type system is way more rigid. C++ is extensible, and has reasonable introspection capabilities. Go isn't extensible (primitives have more capabilities than anything I can implement myself), and it doesn't have real generics.

Heck, it even comes with a tool that makes your code adhere to a standard (and re-orders the import statements, among other things) every time you save the file (go fmt). Have you tried using Go on a Mac/Linux? The experience is extremely pleasant.

Agreed, it's easy to handle and manage code. But that stuff exists for C/C++ too. It's just not standardized.

I'm hesitantly optimistic about Rust.

I doubt it. I briefly had to use Go in a production environment, and to this day it brings to my mind the hours of seething hatred I spent searching in vain through Go's documentation for useful functionality. The biggest problems I can think of off the top of my head are:

• the lack of any serious developer ecosystem.
• the lack of built-in features to offset the first point.
• it makes a whole bunch of changes from traditional language paradigms (making up a whole bunch of stupid terminology)...because! (It's basically at Objective-C levels of batshit.)
• it has a baffling type system; it feels like a whole lot of thought went into it, until you realize you can't actually do anything.
• it's quite a bit slower than Java.

Go is an empty, useless, husk of a language. It's like C, if C didn't have any substantial libraries, didn't let you use any useful shortcuts (in the name of "secure code"), and ran 10 times slower. It will die, slowly and painfully. It's only survived this long because Google has backed it, and it's less used than Microsoft's F#.

I played around with this several weeks ago. The spec is self-contradictory, and code written in it is unreadable...just like Trump.

No it won't; it's been up there for a while now.

Might not be possible; there's too much interactive content.

To be fair, that's git's terminology, not GitSJWHub's.

Also on the topic of version control:

commit -- Save into a repository. In most cases, this refers to a local repository.

branch -- You can fork someone's repository, to make your own copy of it. The copy is its own repository, and is often referred to as a branch when it is unchanged from or closely related to the original, or was created for the purpose of pull requests (see below).

push -- Upload changes to a remote repository, such as Github SJWHub or Bitbucket.

pull -- This can refer to pulling changes and updating a repository locally, or to pulling changes from another remote repository.

pull request -- After pushing a commit to your branch of a repository, you can make a pull request: a request to merge the changes you made on your branch into the original repository.