gojq VS nushell

Yeap i've talked to itchyny quite a lot about various changes https://github.com/itchyny/gojq/issues/153 and also upstreamed quite a lot https://github.com/itchyny/gojq/issues?q=author%3Awader like custom iterators (to allow eval, own iterators and "empty" functions), query marshalling (query rewrite tricks) and a bunch of small things and bug fixes. But the largest change to add a JQValue interface is quite complex, other changes like extended literals is also a bit tricky.

Hmm weird list of changes for https://github.com/wader/gojq/compare/fq...itchyny:gojq:main but i guess it is because i haven't kept my main branch in sync. The fq branch should be based on latest gojq/main as of now. I usually try to rebase as quick as possible.

Let me know if you have any other questions or want to help out! maybe email etc as i usually don't check HN comments replies that often :)

gojq has support for yaml input (via a very annoying argument name) and also has the golang property of "curl binary; chmod; profit": https://github.com/itchyny/gojq#difference-to-jq

It's error reporting is also clang-vs-gcc level wizardry, and I often use it to get a helpful message instead of "ENOWORKY" from jq (I haven't tried 1.7 yet, so it could be better for all I know)

Some competition for https://github.com/itchyny/gojq. I had read somewhere that it was faster than jq - no idea if that's still the case.

JQ has a go implementation usable as a library I see. The project looks fairly active https://github.com/itchyny/gojq

I've been getting a lot of mileage out of https://github.com/itchyny/gojq#readme recently due to two things: its vastly superior error messages and the (regrettably verbose) `--yaml-input` option

I also have https://github.com/01mf02/jaq#readme installed but just haven't needed it

I use gojq with --yaml-input or --yaml-output and flip back and forth between JSON and YAML promiscuously and have 100% jq UI compat, which helps because I use jq a lot. First thing I looked at on yq is '-s', which is 'slurp' for jq. Slightly altered semantics would just trip me up, and it seems like you can make a nearly straight bijection between YAML and jq so you can just do exactly the same things with either one (with some minor exceptions.)

https://github.com/itchyny/gojq

jq https://github.com/itchyny/gojq

github.com/itchyny/gojq -> similar to goawk, except JQ this time

These are just three small examples of what this shell written in Rust allows. The features are many and many more, but I'll leave it up to you to discover and enjoy them; I'm currently playing around with it and it's giving me a lot of satisfaction and immediacy, now it has a fixed place among the tools I use when working! The project is Open Source, so if you want to contribute, I invite you, as always, to do so, I leave you the link to the repo here!

Any thoughts on fish as compared to nushell [0]? It's similar to PowerShell in its philosophy and is also written in Rust.

[0] https://github.com/nushell/nushell

> In PowerShell, structured output is the default and it seems to work very well.

PowerShell goes a step beyond JSON, by supporting actual mutable objects. So instead of just passing through structured data, you effectively pass around opaque objects that allow you to go back to earlier pipeline stages, and invoke methods, if I understand correctly: https://learn.microsoft.com/en-us/powershell/module/microsof....

I'm rather fond of wrappers like jc and libxo, and experimental shells like https://www.nushell.sh/. These still focus on passing data, not objects with executable methods. On some level, I find this comfortable: Structured data still feels pretty Unix-like, if that makes sense? If I want actual objects, then it's probably time to fire up Python or Ruby.

Knowing when to switch from a shell script to a full-fledged programming language is important, even if your shell is basically awesome and has good programming features.

Maybe if the "popular" shells, but http://www.nushell.sh/ is looking better and better

Yeah agreed, especially now that PowerShell is available cross-platform.

Nushell[1] also seems like a promising alternative, but I haven’t had a chance to play with it yet.

[1]: https://www.nushell.sh/

I also discovered an existing discussion[1] related to this topic which includes a link[2] to a "helper to call nushell nuon/json/yaml commands from bash/fish/zsh" and a comment[3] that the current nushell dev focus is "on getting the experience inside nushell right and [we] probably won't be able to dedicate design time to get the interface of native Nu commands with an outside POSIX shell right and stable.".

[0] https://gitlab.com/RancidBacon/notes_public/-/blob/main/note...

[1] "Expose some commands to external world #6554": https://github.com/nushell/nushell/issues/6554

[2] https://github.com/cruel-intentions/devshell-files/blob/mast...

[3] https://github.com/nushell/nushell/issues/6554#issuecomment-...

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-comma...

[2]: https://github.com/nushell/nushell/issues/5027

[3]: https://github.com/nushell/nushell/issues/9310

I found nushell (https://www.nushell.sh) to be an impressive replacement "bash" for Windows

In terms of philosophy, think "Powershell but actually intuitive" : Every data is structured but command names are what you expect them to be. I usually don't even need to look at the documentation.

I liked it so much that I also replaced my shell on Linux with it, so I have the same terminal experience across all OSes