Windows sysadmin here. PowerShell has been great for a long time, well, since at least v5.1, when they finally fixed many of the annoying issues and limitations of earlier versions. I practically live in it the whole day - 90%+ of my work life is in PowerShell these days.

But I question its utility on other platforms, because a lot of the things that makes PowerShell cool on Windows doesn't actually work in Linux or macOS.

Eg: Get-Service (and associated cmdlets). Very handy cmdlet that I use all the time on Windows. On Linux, you'd expect that it'd work with systemd units, but no, that command doesn't exist on the Linux version. Same with Get-NetAdapter, or Get-NetTCPConnection, or Get-Disk and so many other handy cmdlets that I use all the time on Windows, are all missing.

Yet, some cmdlets do exist, like Get-Process or Get-Uptime etc, so I don't understand why many of the commonly used Windows cmdlets haven't been ported over.

Another annoying quirk is how PowerShell on *nix hands off some of the built-in aliases to their native versions. Like on Windows, I always use 'ls' because ain't nobody got time to type Get-ChildItem. Unfortunately when I run this on *nix PS, it runs the native version. And this is a problem because when I pipe 'ls' into a for loop or another cmdlet for further processing, it naturally, doesn't work. To make things worse, this native-or-alias decision making isn't even consistent. Like 'pwd' for example actually runs the PowerShell version, whereas 'echo' runs the native version.

Basically, as much as I love PowerShell on Windows, on *nix it is very annoying to work with. I would much rather work with native *nix shells and scripting languages. And if I really wanted the structured output of PS, I would run Nushell instead, which is far more consistent and useful than the half-baked product that *nix PowerShell is.

I have only ever used Powershell when I had no other options, but a decent number of the APIs feel designed by someone who has never used a terminal. Like they were begrudgingly fulfilling the objective without ever imagining a real use-case.

Naturally, I cannot produce an example off hand, but I was pretty disappointed the last time I had to reach for it and found that a few "obvious" workflows seemed more hacky than I would have expected for a clean-slate terminal language design.

I personally prefer nushell[0] over PowerShell for similar tasks. My main is still Fish, but I occasionally use nushell when interactively exploring structured data (e.g. JSON files because I always forget the jq syntax) and specific nushell scripts I have (e.g. finding all the available nodes with GPUs on a SLURM managed HPC printed as a pretty table), which I find much easier to write than bash/fish.

0: https://www.nushell.sh/

I think for few years MS has tried to be a bit more developer friendly. The Windows Terminal (and no, not what opens running Command Line or Powershell, it is a different application: https://en.wikipedia.org/wiki/Windows_Terminal) is kinda good actually. It’s not Alacritty, but a lot better than any previous terminal emulator. I have also poked around their developer tools and they do seem to make using windows a little less hellish experience: https://learn.microsoft.com/en-gb/windows/dev-environment/

And PS is pretty good, although I haven’t used used PS7 much (if it is a completely new application, why does it share a version number? And why does it not come as the default shell with Windows? Why do they have to make everything so confusing?). It is probably nicer for extended scripting than bash, but honestly I rather use Python for that. For windows admin stuff it is great, but mostly I work with network stuff and it is way too verbose to my taste for simple commands. ping is a lot easier to remember than Test-Connection. I reach for cmd commands like netsh int set ip rather than tab through the verbose syntax of PS for simple network commands. I know you can set up aliases and bash aliases like ls work, but I still feel it os pretty impractical for quick terminal work.

Using it on linux feels so blashemous that I will not entertain such vile and fevilish thoughts. I use linux to get away from the sinful awful things I must do for my livelihood, I tather not use Win applications on my own system unless I absolutely need to. For any serious scripting on Mac… Maybe just don’t?

I can't believe how this opinion got so popular, because I disagree completely with the Bash bashing.

I totally get it for people who only ever used .BAT files (our entire IT department at work). It must feel like a godsend to them. Bash of course never worked for these people; running it on Windows via MinGW/Cygwin is just a bad experience.

But the relentless bashing of Bash itself and the longstanding Linux (and Unix) ecosystem alternatives in general is unjustified in my opinion.

Bash itself is elegant, powerful and concise, and just works on Linux. You can write spaghetti code, but you don't have to. Readable scripts are just as easy. "Skill issue" if you will.

And yes, Bash-isms exist, and I got reminded of that fact when Ubuntu shipped Dash as the default /bin/sh shell for a while or when I'm on macOS. But it's really not a huge deal: just use the real !#/bin/bash and ignore the "um actually in Posix..." complainers on the internet.

I do appreciate that Windows finally has a capable scripting language, and while I don't like the lengthy syntax / cmdlets, I also see some benefits. But Bash is still great nonetheless.

Powershell is so good that I find it strange it didn't get to be default at least in some Linux distributins (or some proper fork/redo of it). I even used it for integrative feautures for some of my state projects serving millions of user. The fact that I have proper language, designed for shell, very efficient, not needing an IDE or anything, is quite liberating.

I use it for all kinds of stuff. Here is an example that creates MusicBrainz collection from my local audio folder, solving the browsers proof of work in between: https://github.com/majkinetor/musicbrainz-userscripts/tree/m...

If I am nitpicking, performance could be better, although MS did a lot in previous years and even that just in theory as I was never really blocked by that. But if it could be performance beast too, I would think we can stop researching new shells and just use it everyhwhere.

JSON support is amazing - you don't learn anything new like with jq, it just works. Selecting stuff is amazing, I love it more then SQL. HashTables are epic for configuration (you have a real language in it, unlike in lets say YAML).

Scripts that look horrible in bash are few lines of beautiful in pwsh.

If you didn't try it, or didn't give it a chance, you are missing out for sure.

  Get-ChildItem -Filter *.txt -Force

  ls -la *.txt

yeah there's a reason they call it POWERShell, not EasyShell, SimpleShell or IntuitiveShell.

Eye-bleed syntax, but I guess my agents don't mind that.

I recently installed Powershell 7 because apparently that is different than the powershell that comes with windows. It's great, but, now I have at least 3 different Powershells in my OS? Why? And they function very differently. I had to change all the defaults for opening a new terminal or new shell window in Windows because many of the defaults kept giving me one of the old powershells which I wouldnt figure out until my commands and scripts kept giving errors, since they use commands which only exist in Powershell 7. Cannot believe Microsoft decided to copy Python's original sin and create several conflicting, coexisting installations of the exact same thing, but different incompatible versions. Whyyyyyyyy

Regarding the article: Corbin Davenport is an amazing name. Nice article too.

It’s a mixed bag. There are some really nice things. Like how easy it’s to get tab-completion for custom scripts, scripts in general are a lot more readable than something like bash. I also like the ability to do advanced things by calling .NET stdlib.

On the other hand, the considerable slowness or JIT lag kills me. Same with the crazy verbosity of everything. You end up setting up so many aliases that your shell ends up being very very different from any other pwsh. I setup or expect a lot of aliases on bash too, but pwsh is multiple orders of magnitude that. Like I always hate when I ssh to a machine and something as simple as `ll` doesn’t work and I need to spell out `ls -alh`, but with pwsh it’s EVERYTHING. Until very recently simple things like -e didn’t exist.

But the slowness is what really kills me.

A lot of the frustration I've seen with PowerShell from longtime Linux users is that there's an expectation that everything is a file in the linux/bash idiom, and can be interacted with that way (tangent, I think this is where a lot of vexation with systemd comes from), where Windows and the NT kernel enforce the concept of everything is an object.

It's a much more powerful system, but users who are used to being able to do, well, whatever they want with no rules get frustrated with the syntax and "correct way" to do a thing when you just want a stupid string (it's me I'm users). It's very similar to Rust in that way, where once you stop fighting the borrow checker life becomes so much easier; once you stop fighting the objects, you stop getting in your own way and it becomes a much more productive experience.

I've written a lot of powershell in my time..

PS is really powerful for Windows OS level concepts and enterprise software that have good modules (AD, IIS, Citrix). However it has so many semantics that can burn you; non-strict mode, implicit type conversion, ordered null checks [1], not to mention the amount of boilerplate in a module and the runtime overhead. At a certain scale/complexity you need to graduate to using C# and .NET.

[1] https://learn.microsoft.com/en-us/powershell/utility-modules...

Part of setting up a new Windows or Linux machine for me is installing the latest PowerShell 7+.

My $PROFILE has custom modules that comprise ~9,000 lines of PowerShell. Anything "script-y" that I think I'll do more than a few times becomes a new function in one of those modules.

On Windows, I haven't used `cmd.exe` in at least a decade.

And part of my root `AGENTS.md` is "Please use PowerShell when generating scripts, unless I specifically ask for a different language."

Works a treat.

Once you get used to passing objects between commands - not just text - the thought of using a Unix-y shell feels like visiting the past.

Powershell is great, however I've recently started using file based apps to replace some of the more complex powershell scripts. Top level programs in C#14 can make equivalent powershell functionality look a bit dated.

Powershell is still indispensable for things like deploying build artifacts to production servers. Anything where you need to provide a secure command link between two windows boxes.

Most of my GitHub actions are a thin yaml wrapper around az login and powershell session setup. From that point 99% of the magic resides in a proper C# codebase.

PowerShell is nice. It also reads well. What does sed, tar xvf, jq curl -k actually _do_?

And then passing text lines with > like a caveman. Does bash not have the concept of objects?

You write Invoke-WebRequest and it invokes a web request. Easy.

I have to admit it's better than scripting in Bash, but in my personal opinion that's a bar so low it's on the ground. Don't get me wrong, I'm grateful that shell scripting is a thing. But my policy for a decade has been that when I need any logic more complex than a simple string matching in an `if`, I should back away from the computer and then rewrite it in a reasonable scripting language.

Powershell is definitely a reasonable scripting language; it's mainly its verbose command names and new-to-me syntax that have made me put off learning it so far. I suspect that it looks more familiar and welcoming to .NET devs though.

unlike macos's curl, powershell's curl alias for Invoke-WebRequest checks the revoke list and will protect you from mitmproxy --emudhra

My favorite PowerShell feature was barely mentioned: structured output!

Life is too short for parsing ad-hoc data formats from the 80s, and the "everything is a string" approach from *nix is a major contributor for the unreliability of shell scripts.

Does it have automatic error handling, so that if one command fails, the whole script fails too? Last time I tried it, I needed to write

   if ($LastExitCode -ne 0)

after each command.

Comparing to Bash is cheating, though. Try comparing it to Python. We don't need to have one tool for every task. On Linux we have always had support for multiple scripting languages. Use the right one for the job.

Been using oh-my-posh in powershell, and some aliases to map commands for my old linux sysadmin brain. Everything mostly works to get the job done, even got vi and scp. Its just another tab in my windows terminal with my ubuntu tabs.

I use Powershell a fair bit, Powershell is not good. I can see why people delude themselves into thinking its good: it does in fact let you administer systems, and it lets you avoid the pitfalls of stringly-typed scripting like bash or batch files.

But being technically capable of something and being good at something are different.

Powershell tried so hard to be user friendly that it wrapped around and ended up being user hostile. There are far too many footguns and "magic" features that do nothing but sit around and wait for you to forget about them so they can break everything.

Just look at the comparison -eq as an example. First off, this is the same syntax powershell uses for named function arguments. Why on earth would you do this? Because operators like this exist, I now need to ask myself "is this a named function argument, or was the script author trying to use an operator here?" for EVERY NAMED ARGUMENT. But wait! That's not actually true! After all, powershell has two ways to call functions. Because powershell is like the red-headed stepchild of the other dotnet languages, when you want to call functions on assemblies, you can use a more conventional

[complex.syntax]::F(x, y)

So there you can use normal named arguments without having to second guess what they are right? Haha no jk powershell doesn't have a syntax for calling a C# function with named arguments, you just have to work out the positions and pass null (sorry, I mean [type]::Missing) in for any optional named parameters you didn't mean to supply a value for.

ANYWAY, back to the -eq operator. You might THINK that an equality comparison operator would return a boolean, but that is because you are not as smart as the PowerShell devs. The powershell devs know that an -eq operator should actually act like a filter if the left hand side is a list, returning the elements of the list that match the right hand side. Now in my head, this is the most astonishing behavior (least astonishing is just returning false if the types don't match, next up is a list of {true, false, ...} that comes from from mapping the comparison across the list), but that is because I am not as smart as Bill Gates.

Now you could maybe defend this behavior if it were easy to keep track of your types in powershell. But powershell actively makes this more difficult by doing things like automatically converting [int] into plain int when the array only has one item in it! So because powershell tries to be helpful and give -eq more power, then also tries to be helpful by unwrapping your one-item-lists because surely that's what you want, you can very quickly find yourself in a situation where you the scriptor are finding bizarre errors caused by having -eq insert lists of things where you expected booleans to be.

This kind of combinatorial-inconvenience is pervasive in powershell.

I'm all for "lets make an object-oriented scripting language", but there are so many unforced errors in the powershell language design that its hard to recommend.

Yeah, you're not the first to discover this, but I'm curious how you'll feel in a few years. I recall three years ago my wife got a new gamer laptop and had nothing to do with her old one. I don't game, but got curious about playing around with Hyper-V. Packer at the time had no working builder for it, so I figured I'd make my own to create Linux VM images I could run on Windows, sort of "roll your own WSL." I quickly discovered PowerShell and unexpectedly fell in love with it. It only took me a few hours to have a working implementation roughly identical in function to Packer but without having to write any compiled code at all. It was pure PowerShell modules. This was before LLMs. I wrote it all myself, in a language I'd never used before, using documentation I had to search the web for using a plain search engine, and it still only took a few hours and did exactly what I wanted.

It didn't revolutionize my life, though. Three years later, I no longer use Windows for anything and revert to plain POSIX shell whenever possible for all scripting, largely for ecosystem reasons. Everyone else I work with is using that. I'd analogize this to challenges living downtown in the middle of a busy city. My roads are terrible, largely because they're so patchwork due to utilities and construction teams needing to tear out pieces, fix or add something underground to accomodate new building, then put the road back together again. It means you'll have 30 meters of regular concrete, then 10 meters of asphalt, then 20 meters of some pebbles in glue looking monstrosity. It works well enough for cars with large rubber tires and suspension systems, but it's hell for skateboarding. Go out to the suburbs where the entire road is all the same substance and it's smooth sailing.

Hacker News and the web more generally seems like these discussions about tooling and dev experience end up dominated by solo developers. If you're the only person working on a project, let alone these days with LLMs where half the breathless posts are about software where you're not only the sole developer but also the sole user, do whatever you want. It's like moving all the furniture around in your room every single day when you live alone. Go for it. But if you have a spouse, whether or not your new design is better than the old one, that's kind of rude. When you're part of a team, you have to eventually settle on all doing roughly similar, predictable things so you're not disrupting everyone else's workflows and expectations, even if those roughly similar, predictable things are suboptimal and there's a better way.