I would agree that Powershell has less quirks than bash which sometimes feels like one big quirk. But I think they could do much better. During my project we ran into a ton of issues around scope, return values from functions and other stuff that were really hard to deal with. You don’t see that with small scripts but our project has thousands of lines and becoming hard to manage. Now some smartass will say that Powershell is not designed for a project of that size but the cmdlets almost force you to use it for certain types of tasks. It would be pretty difficult to rewrite that code in another language.

Once you realize that you need classes to return values and functions don't return values I (admittedly not an expert) don't see anything more complex beyond that.

This thing itself seems like a quirk but again I'm not an expert so don't know how this was designed.

I wrote quite a lot of PowerShell code. I really like the language, except when I don't. And return and outputs in general are among the most infuriating points.

> In PowerShell, the results of each statement are returned as output, even without a statement that contains the Return keyword. Languages like C or C# return only the value or values that are specified by the return keyword.

I don't want all output, no, please, I don't want it. I want something specific and not all the junk around it. So you have to turn into ugly measures like out-nulling everything or searching through your output because there is always possibility that some commandlet outputed something you were not expecting and it will return before the value you actually wished to returned.

And classes are nice and all, but lot's of stuff are not compatible PowerShell 5. And there is also the added complexity.

https://docs.microsoft.com/en-us/powershell/module/microsoft...

Reading through the examples of the unexpected behavior in so many cases is flabbergasting.

Function return values is among the worst ideas the PowerShell designers dreamed up. A function will (more or less) return anything output to the terminal. This is a particularly bizarre decision considering how difficult it can be to get many Windows commands to be completely silent. Error handling, redirecting output, etc. all fail in many circumstances. It was completely aggravating. It has been a few years, so hopefully that's changed.

Of course it didn't, look at my sibling comment for a link to the updated doc.

I don’t remember the exact details but for example loading classes that reference each other was hard unless they were all in the same file. I ended up writing a preload step that would combine all library files into one big file and execute that. In general I found it hard to write reusable code once that code started referencing each other. Maybe there are ways around that but it seems kind of stupid to create a new way of achieving what other languages have already solved decades ago.

If cmdlets were easier to use i would probably have used a proper language like csscript or C# instead of Powershell.

With modules my pwsh 6 usually starts between 700ms - 2s. Not a big deal to me though.

Cold start? My cold start is 20 seconds but after that about the same as you so I did a rough "average" to try to convey that :)

If you have modules in your module path that don't declare their exports in the manifest, PowerShell has to inspect everything to find all the cmds. This is often what is going on when you have terrible startup times.

Look who's here! Everybody Jeff is the chief architect of Powershell and someone pretty high up Microsoft right now.

Jeff hello, if it's alright i wanted to discuss the target audience of Powershell.

As I understand Microsoft is currently targeting azure users and enterprise sysadmins. I would like to propose that You add features to it that bash and zsh power users take for granted and target the linux community so that it gets more cred and in the open source hackers community and consequently more usage by regular people. Basically the developers developers developers thing from your old boss...

To be honest, right now I can recall anything I'm missing, fzf works, so does z. I will look at the startup time issue (my biggest one right now, I literally had PS1 as my login shell briefly ) ...

Step by step we've been doing more and more focused on Linux users. If you take a look at our telemetry - it is clear something is working because Linux usage is through the roof!!!

https://aka.ms/psgithubbi

I don't want to make any news here but in a bit, the team will publish a blog articulating where we'll be focusing our next release. I think you'll like the direction we are taking.

Jeffrey Snover [MSFT]

That's great to hear, thank you. I look forward to more command line warrior friendly features

Yes that is cold start. I wonder where your slow down is. I only use 2 modules and have a rather small profile to load though.

I have noticed that profile scripts slow down my startup a lot.

I was happily surprised by Alacritty that launches Powershell much faster than Powershell itself (??) on my laptop at least.

PowerShell is a shell - a program that takes input, does work, and returns output.

Alacritty is a terminal - a container that transports user inputs to programs (like shells) and prints program outputs to the screen. The terminal owns the actual graphical window you interact with.

The default terminal on Windows is the Windows Console. Windows comes with two shells, the Command Prompt (cmd.exe) and PowerShell. Both of these run on top of the Windows Console.

There is also a new terminal in development by Microsoft, called the Windows Terminal. It's much more modern due to not having to be backwards compatible.

The start time is a major disadvantage behind Powershell. It takes 3 seconds to load even if you disable profiles completely versus <1 second for Python, Ruby or Bash.

Process creation on Windows has always been significantly slower than Unix. That is why PowerShell is skewed towards "built-ins" vs launched applications. The ramification of that is slower startup times.

Interesting note - it is also the reason why PowerShell was able to adopt the more natural Verb-Noun model for cmd naming. In Unix, this would produce a huge # of files OR and you couldn't do "VERB NOUN" because then you would have to multiplex on the VERB. Unix's "NOUN VERB" is the result.

BTW - VMS DCL stepped on all these rakes which is why it is have VERB/NOUN and half NOUN/VERB. A complete mess.

Jeffrey Snover [MSFT]

Would you consider a powershell server process to speed up startup?

This is an idea we've discussed, but not something we're investing in right now. It could also solve the sudo/elevation problem for cmdlets. However a privileged service would also bring more security concerns.

Hey Steve you're doing a great job with PS! Thank you for all the hard work you and your guys are doing. You are also exceptionally responsive on GitHub.

Yeah, it makes it useless for short scripts. But I think a lot of that’s the .NET runtime start-up time. So getting rid of it might be challenging.