Which is over 5 years after Powershell became common.

Yes but some would argue Psh didn't become useful until release 6 in 2018.

As long as I have to write C# wrappers to launch commands like I would in unix with xargs or parallel in PowerShell it's still not the ticket.

And neither of those are native parts of shells but external applications, dare I say, just like the C# wrappers. (Especially parallel, since it's nowhere close to default install, and has very pesky license notice).

OTOH, PS 7.0 added ForEach -Parallel

Yeah, but & is a thing and will do the job nicely as long as you don't try to pipe output to the same file... also, you can invoke pretty much any command with xargs... the issue was escaping escaped stuff with PowerShell. Hopefully things have gotten better.

You shouldn't need to, unless your PowerShell installation doesn't support Invoke-Command, or ForEach-Object -Parallel...

Yeah... shouldn't need to but... there are issues with escaping command line parameters with invoke-command and ForEach-Object that prevent parallelizing older cmd-style command line applications. The work around is to write a wrapper in a compiled language and use PowerShell to invoke the wrapper... There's a lot of really cool stuff in PowerShell.

> there are issues with escaping command line parameters with invoke-command and ForEach-Object that prevent parallelizing older cmd-style command line applications.

Can you tell me more? So I know what to expect when I hit such issue myself.

> The work around is to write a wrapper in a compiled language and use PowerShell to invoke the wrapper...

Wonder if you need to really break out of PowerShell for this.

Recently when doing some scripting at work, I ended up writing .NET code straight in the script. It looks like this:

  $someCSharp = @"
  using System;
  //...
  public class Foo : Bar {
     public override object Baz(Quux arg) {
       //...
     }
  }
  "@
  
  Add-Type $someCSharp -ReferencedAssemblies C:\Path\To\Some\dependency-I-need.dll

This makes PowerShell compile your code into an in-memory assembly and make it available in the session, just as if it was an external .NET type. You could probably make a module out of it. Hell, cmdlets are .NET types underneath, you can make new ones from C#, so you could probably make such ad-hoc .NET classes available as PowerShell cmdlets.

I suppose using a proper .NET development environment for this would be more kosher; I arrived at the solution described above because my needs were simple, like binding .NET regex engine to SQLite (to get REGEXP operator in queries), or convincing Invoke-RestMethod to stop checking certificate validity.

Still, I love the capability, the fact that I can just drop into C# in the middle of the script. It's one of those things that make me think of Lisp machines and Common Lisp the experience of being able to deeply interact with your environment, and the joy of writing "scripts" that are automatically AOT-compiled (like with SBCL implementation of Common Lisp).

That would be... an opinion. Not very grounded one unless one's whole base for it was "I couldn't use it on Linux".