This is in line with my experiences with powershell (or powershit as we refer to it).

The canonical example of the complete failure and total friction is in the simple case of obtaining a file from a web server and sticking it on disk. This is the steps:

1. Try various built in cmdlets. Eventually find one that works.

2. It's a big file and gets entirely buffered in RAM and takes the machine out. You don't get the privilege of finding this out until you try dragging a 20GiB vhdx image from a build server to plonk on your SCVMM platform. That conks it completely.

3. So you think you'll be clever and just use curl. Oh no there's a curl alias!

4. Every damn machine gets sent a reconfig to remove this stupid alias.

5. Then when you do get there you find that the curl output pipe just pukes multibyte garbage out. 20GiB of it that took a long time to come across the wire.

6. You tell curl to save the file directly. Might as well have used cmd.exe by now!

So 8 Googlings and 3 hours later you got a fucking file. Every time I use powershell that is my life.

    man iwr

Oh, there's an OutFile parameter. Let's see what it does

    man iwr -param outfile

How nice, it writes the response directly to a file instead of to the pipeline. The curl alias actually points to the very same cmdlet.

Not to excuse bad examples on the internet (there are lots of people who fail to grasp PowerShell and still try to write articles and how-tos), but PowerShell having built-in documentation for commands and parameters is actually fairly easy to figure out from within the shell. Admittedly, once you learn the basic half dozen or so cmdlets you tend to use all the time.

You're free to ask me (or on SO, I tend to answer PowerShell questions there) if you're having trouble. Figuring above out took literally just 20 seconds. Really. I'm kinda sick of people cursing and blaming tools just because they're different from what they're used to. If I did the same and complained about bash and Unix (which I rarely find the need or time to learn) I'd be tarred and feathered in seconds ...

It doesn't work for large files. Try iwr with outfile on a 16Gb file on a 4/8Gb machine.

Knowing all the edge cases, exceptions and places where reality breaks down is the problem.

Where software should indeed work with the principle of least surprise, Microsoft have patented the principle of most inconvenient surprise.

Also SO has one small comment about this which didn't exist when I discovered it. I had to use windbg to dump the CLR heap and find out that there were a crap ton of buffers...

And that's every day using powershell. It's even worse if you trip over someone else's cmdlets which aren't aware of the correct harry potter style incantations to issue that don't cause the universe to implode.

The whole thing is a joke. A bad one.

Unless you also write things to the pipeline via -PassThru specifying -OutFile will read in 10K chunks and write them to the file. No memory apart from that buffer is used. Look at the source, it's public. My PowerShell instance uses 38 MiB of memory the whole time during the download, regardless of the file size.

What's in your $PSVersionTable?

I'm doing this on windows 2008 server.

5.1 on Windows 10. Admittedly, I never really tried iwr on older versions. Heck, the last time I tried downloading something with PowerShell to a file I went the WebClient.DownloadFile route, so it's been a while.

You can probably install a more recent version of WinRM on that machine, though (or by now probably the open-source version of PowerShell).

To be fair there are many, many examples of downloading files using System.Net.WebClient. In fact that is how the first several search results for `powershell download file` tell you to do it despite Invoke-WebRequest being included in PowerShell since 2012. `get-help download` doesn't return anything useful. Contrast that with `apropos download`, which at least on FreeBSD includes wget in the search results.

Well, for many years I had that experience every time I tried to use UNIX command line. I think it's just the issue of familiarity.

How many Googles per line do Unix shell scripts need, assuming equal familiarity with both? As for me, I understand PowerShell fairly well, but hate having to deal with Unix utilities and for me the amount I have to google to get stuff done on a Unix command-line is significantly higher than with PowerShell.

It's just that once you learn how to use a tool you don't have to think about how to approach a problem anymore, you just do it. And then, when learning a completely different tool you have to learn again. Surprise.

I should've explained the background - these are C# coders coming to Powershell, not Unix admins.

The problem with Powershell is that it tried to have its cake and eat it too - it wants the lightweight IDE of Unix-philosophy tools, but the detailed structure of C# objects. The problem is that the former is tightly tied to the simple common api of raw text, and the latter is inherently dependent on an intellisense-oriented IDE and static typing that heavily hints the names and parameters of useful actions.

Powershell manages to combine the worst of both worlds - objects means more complex APIs, but without the powerful IDE guiding you around those APIs.

I'm sorry what? Powershell has to be one of the better documented systems I've used in quite some time, and the sytnax lends itself to a certain "learning velocity" if you will. I also find that the general standard for tooling is a bit higher than say, bash.

It's also been really neat to see how well Powershell lends itself to extending other applications.

For people who don't know the standard Unix tools, I expect much the same.

Well, sure, if you don't know PowerShell or use it often you'll need a lot of help. That just sounds like an argument for slavish adherence to existing conventions till the end of time -- in which case why bother with a new language?