So when I say the language doesn't matter, that doesn't mean programming languages don't have certain advantages but until you really understand a few languages, advantages don't matter. Understanding a system well enough to solve 90+ percent of your computing problems is more important. With most modern languages you can implement just about anything: systems utilities, network programming, web applications, etc. That doesn't mean there isn't a right tool for the job, but you can learn an awful lot while using the wrong tool for the job. I don't have a lot of scientific evidence to convince you, but I do have a couple stories about stuff I've made, mostly using the wrong language, and managed to get things working.
I'm a sys admin by trade but when a project manager heard that I knew how to code they threw me head first into developing a desktop application for managing shared data across disparate storage platforms, a non trivial task for being a novice. He'd never bothered to ask what my experience was and probably wouldn't have chosen me if they'd known.
For those who are curious, up to that point the only non-trivial things I'd done in production where a batch file for scraping url's from an Excel spreadsheet and creating .url files from those, not super easy in MS batch. Second, a collection of programs for migrating Windows desktops from one domain to another while written in C#. This is where I cut my teeth and it only worked because I was backed into a corner with the language choice. I was stuck with C# so looking at other languages or code samples which already did what we wanted wasn't an option, even though I didn't know the first thing about the language. The fact that my last project had been in C# was all they wanted to know. Where else are they going to find a desktop support tech who can use Visual Studio? The fact that a professional developer could have done the job in two weeks was inconsequential, I had the advantage of being naive and financially cheap.
After that I wrote a few other apps to help my old co-workers. One, a C# cmd line utility, cleared out old GroupWise MAPI profiles from the system registry. Attachmate has a product which does this but it didn't load registry hives for users who aren't logged in, that's what mine did differently (it should be noted that Attachmate has a newer version of their utility that does this and works way better than mine did, I just didn't know we were the outdated one).
The next was a VBScript that forcibly installed a particular piece of software on a desktop and fixed any configuration or corrupted installation problems. This required having a resilient package management system (not MSI, I basically reimplemented Debian packages in Windows with VBScript), the ability to query AD for configuration information based on the OU a workstation resided in, and a distributed log aggregation system so we could collect metrics on how effective the tool was. VBScript is probably one of the last languages I should have used for all of this but I learned an awful lot in the process and the fact that VBScript was mandatory kept me focused on the task at hand. This worked magic and was able to get 90% penetration into the desktops in our enterprise when the vendor supplied method was stuck at just below 50% (subversive problem solving and a little scripting can go a long way).
The most recent is a Windows service that parses event logs, converts the timestamps from MS brain dead time to UTC, and serializes them to out to a json file for other tools to munge. This was done in PowerShell and while running on .Net and written in C#, it does not share the same memory characteristics as .Net. Namely if you overwrite a local variable inside of a long running loop, the dereferenced values it used to point to are never released from the heap. Move that local variable and it's associated logic into its own function and call into it from inside the loop. That's the only way I've found that works, even calling [GC]::Collect() on each iteration does nothing. I think we can agree that PowerShell is the wrong language for writing a Windows service.
So I've written some really awful software in languages that weren't right for the task but being constrained by the language choice forced me to learn how to solve problems rather than jump to another language. If you're learning to program on your own, set some goals, set some constraints on your tools and don't cheat. The constraints and roadblocks are what force you to think differently, that's where innovation and inspiration come from.