Nushell is definitely interesting, and I'm glad it exists, but I'm not using it because of at least a couple of major reasons: - It reimplements all commands.

Nushell is definitely interesting, and I'm glad it exists, but I'm not using it because of at least a couple of major reasons: - It reimplements all commands. You're not actually using GNU coreutils, but Nushell reimplementations of ls, rm, etc. See [1]. I understand why it's done, but this has many drawbacks: 1. All existing shell examples and documentation spanning decades are useless. Nushell commands try to replicate existing UIs, but they invariably must be incompatible to support all features and deprecate unnecessary ones, so the only valid source of documentation is Nushell itself. 2. Nushell-specific bugs[2,3]. This goes without saying, and will improve as the project matures, but experiencing bugs with core commands is jarring. I've never had that with GNU tools. 3. Unsupported commands won't have any of the benefits, and you'd still have to parse their output in the traditional way, or use a Nushell helper. How often this happens will depend on your use case, but you'll always depend on Nushell for integrating that command in your workflow. - Related to point 3, Nushell is building an entirely separate monolithic ecosystem, which goes against the open ideology of Unix. This is similar to BusyBox, where you always have to be aware you're not using GNU tools, but some slightly incompatible equivalents. More importantly, this approach doesn't scale. There will always be new commands that target POSIX shells, but not many commands will be written specifically for Nushell. I appreciate what projects like Nushell and Murex are trying to address, but having a saner scripting language and passing structured data in pipelines is not worth the drawbacks for me. For one, Bash scripting is not so bad if you set some sane defaults and use ShellCheck. Sure, it has its quirks, but all languages do. Even so, the same golden rule applies: use a "real" programming language if your problem exceeds a certain level of complexity. This is relative and will depend on your discomfort threshold, but using the right tool for the job is always a good practice. No matter how good the shell language is, I would hesitate to write and maintain a complex project in it. And for general QoL improvements with interactive use, Zsh is a fine shell, while still being POSIX compatible. [1]: https://github.com/nushell/nushell/blob/main/crates/nu-command/src/filesystem/ https://github.com/nushell/nushell/blob/main/crates/nu-comma... [2]: https://github.com/nushell/nushell/issues/5027 https://github.com/nushell/nushell/issues/5027 [3]: https://github.com/nushell/nushell/issues/9310 https://github.com/nushell/nushell/issues/9310