Wow. I just googled the user you mentioned. First, a different user names some very good reasons to use Nim:
* <https://github.com/byt3bl33d3r/OffensiveNim#why-nim> That repo is labeled "My experiments in weaponizing Nim". And that user gives credit to @ShiteSecure for figuring out the key compilation flags to make Nim useful for certain kinds of attack: By default, Nim doesn't generate PE's with a relocation table which is needed by most tools that reflectively load EXE's. To generate a Nim executable with a relocation section you need to pass a few additional flags to the linker. Specifically: --passL:-Wl,--dynamicbase Run So by default, Nim is actually not so good. You have to know the secret sauce. That makes me feel slightly better. Anyway, I think it's a huge compliment that malware authors see the great utility in Nim. That README also credits yglukhov's nimpy and jnim libraries. People are starting to see the light. Where I work, there are lots of PhDs who are very smart at specific things, but they are surprisingly timid at adopting new ideas. They are reluctant to move away from C++ unless they see their peers move first. (For example, Nvidia does not support Nim for Cuda, even though I did a successful hackathon project in Nim with a GPU coder from Nvidia. And Google does not support Nim for tensorflow etc.) And management is afraid of any language not supported by a large company. But malware coders use whatever tools actually work best. This might be just what we need to open some doors. Of course, we also need many, many more great libraries, including some mentioned at * <https://github.com/byt3bl33d3r/OffensiveNim#interesting-nim-libraries> and also more specific libraries like Arraymancer and SciNim.