3 ms·

So your answers just confirm my 'angry dude' bullet list. As far as I can see, the only really problematic one is startup time, which is surely something that

So your answers just confirm my 'angry dude' bullet list. As far as I can see, the only really problematic one is startup time, which is surely something that will be resolved in the future. I witnessed this only rarely while I use PowerShell on Windows and Linux - it was on windows and it was on VM with very slow disk, and some modules that each keep functions separated by files. I welcome nushell development, but you can't really compare it to pwsh - even if they continue developing it, its decade or so from being usable as main shell. > you grossly overestimate the “awesome”. Nah, its awesome. I save bunch of time any time I open the PowerShell. And any time when one tries to be quicker in some other language one is not, eventually.

jen20 6y ago
In that case you cannot see sufficiently far: telemetry on by default is a non-starter. If the startup time were going to be fixed “real soon now”, it would have improved since 2006. It has not, especially when basic usability enhancements like “posh-git” are enabled. > [nushell is a] decade or so from being usable as a main shell News to me. I replaced Powershell with NuShell.
- majkinetor 6y ago
  > it would have improved since 2006 cross platform pwsh is just few years old > I replaced Powershell with NuShell. Sure, you can replace it with LOLCAT either, its totally legit. Regarding startup time, I can't believe there is such drama. If that troubles you so much, you can easily workaround it by always keeping powershell process pool ready in the background (1 or 2 suspended instances until you use them).
  - jen20 6y ago
    > cross platform pwsh is just few years old It's slow on Windows too.
  - scbrg 6y ago
    > you can easily workaround it by always keeping powershell process pool ready in the background (1 or 2 suspended instances until you use them). This is a pretty absurd take when the discussion is about alternative shells for writing scripts. Shell scripts are everywhere. A fairly heavily used UNIX box might easily execute hundreds of shell scripts every minute. A startup time of several seconds makes it completely unusable.
    - majkinetor 6y ago
      Not sure what to tell you to break your bubble. I have literary thousands of pwsh scripts running in critical gov projects in production, most of them as part of CI, CD, build and automatic test but some of them serving millions of users. I had dozen of such projects in previous decade on Windows and several on Linux and never had any significant problem with slow startup really. Sometimes it happened that some machines had slow startup but team usually fixed that one way or another. Pattern of usage of bash scripts where hundreds of shell script run every minute is IMO not something you should brag about in systems architecture. And pwsh is different - it has modules which are encapsulated and you don't have to start another instance of shell to prevent mingle. Parallelism ofc still benefits from faster startup.
      - scbrg 6y ago
        > I had dozen of such projects in previous decade on Windows and several on Linux and never had any problem with slow startup really. OK. So then startup time is not slow? Well, then it's of course a non issue - but then I also don't see why a process pool would be required. > Pattern of usage of bash scripts where hundreds of shell script run every minute is IMO not something you should brag about in systems architecture. Yet, you just did :) Anyway, it was hardly intended as bragging, rather than just stating facts. Lots of stuff are shell scripts. Lots of user facing commands are wrapped in shell scripts. Of the ~3k commands in my $PATH, around 500 are shell scripts. You may not think this is a good state of affairs, but it's still a fact. (And it's quite unclear to me what's so bad about it - an excellent use for scripts is providing environment for other programs.)

jen20 6y ago

In that case you cannot see sufficiently far: telemetry on by default is a non-starter. If the startup time were going to be fixed “real soon now”, it would have improved since 2006. It has not, especially when basic usability enhancements like “posh-git” are enabled. > [nushell is a] decade or so from being usable as a main shell News to me. I replaced Powershell with NuShell.

majkinetor 6y ago
> it would have improved since 2006 cross platform pwsh is just few years old > I replaced Powershell with NuShell. Sure, you can replace it with LOLCAT either, its totally legit. Regarding startup time, I can't believe there is such drama. If that troubles you so much, you can easily workaround it by always keeping powershell process pool ready in the background (1 or 2 suspended instances until you use them).
- jen20 6y ago
  > cross platform pwsh is just few years old It's slow on Windows too.
- scbrg 6y ago
  > you can easily workaround it by always keeping powershell process pool ready in the background (1 or 2 suspended instances until you use them). This is a pretty absurd take when the discussion is about alternative shells for writing scripts. Shell scripts are everywhere. A fairly heavily used UNIX box might easily execute hundreds of shell scripts every minute. A startup time of several seconds makes it completely unusable.
  - majkinetor 6y ago
    Not sure what to tell you to break your bubble. I have literary thousands of pwsh scripts running in critical gov projects in production, most of them as part of CI, CD, build and automatic test but some of them serving millions of users. I had dozen of such projects in previous decade on Windows and several on Linux and never had any significant problem with slow startup really. Sometimes it happened that some machines had slow startup but team usually fixed that one way or another. Pattern of usage of bash scripts where hundreds of shell script run every minute is IMO not something you should brag about in systems architecture. And pwsh is different - it has modules which are encapsulated and you don't have to start another instance of shell to prevent mingle. Parallelism ofc still benefits from faster startup.
    - scbrg 6y ago
      > I had dozen of such projects in previous decade on Windows and several on Linux and never had any problem with slow startup really. OK. So then startup time is not slow? Well, then it's of course a non issue - but then I also don't see why a process pool would be required. > Pattern of usage of bash scripts where hundreds of shell script run every minute is IMO not something you should brag about in systems architecture. Yet, you just did :) Anyway, it was hardly intended as bragging, rather than just stating facts. Lots of stuff are shell scripts. Lots of user facing commands are wrapped in shell scripts. Of the ~3k commands in my $PATH, around 500 are shell scripts. You may not think this is a good state of affairs, but it's still a fact. (And it's quite unclear to me what's so bad about it - an excellent use for scripts is providing environment for other programs.)