Jless – a command-line JSON viewer (written in Rust)(jless.io)
jless.io
Jless – a command-line JSON viewer (written in Rust)
https://jless.io/
54 comments
Funnily enough I also submitted the same two days ago (I didn’t saw the original show HN)
https://news.ycombinator.com/item?id=30435576
https://news.ycombinator.com/item?id=30435576
Buuuut, this one doesn't have the "written in Rust" in the title
Author here! When I originally submitted it, it didn't get a lot of traction (it got on the front-page via the second chance pool a couple days later), and I definitely regretted not including "written in Rust" in the title. I'm acutely aware of HN's love of Rust, and the subsequent grumbling about always bringing it up that something is written in Rust, so I left it out with the false illusion that not mentioning it would make it more "pure" or something.
But I was also pretty confident that I made something useful, and, in hindsight, I don't think I should have preemptively felt bad about using some "cheap" form of marketing to get people to see it. I have really conflicting thoughts about marketing and self-promotion from my experience trying to show people my other project, plaintextsports.com [1] (live sports scores in plain text with no ads or trackers so it loads instantly! I think the HN crowd would love it!). There's a weird line between marketing and advertising and self-promotion, where one is "ok", but the other is frowned upon. It's also a tale as old as time that the better marketed but technically inferior product wins out. (AC vs DC initially, Betamax vs VHS!) How much of success is being brazen enough to ignore those norms and shamelessly promote something? Should it be considered shameful to promote it in the first place?
In this case, being written in Rust is definitely a feature, as least when comparing tools! fx [2], a similar tool that made the front-page a couple months ago runs using Node, and I'm sure jless can handle bigger files and uses less memory (though admittedly I haven't actually verified this).
[1]: https://plaintextsports.com
[2]: https://news.ycombinator.com/item?id=29861043
But I was also pretty confident that I made something useful, and, in hindsight, I don't think I should have preemptively felt bad about using some "cheap" form of marketing to get people to see it. I have really conflicting thoughts about marketing and self-promotion from my experience trying to show people my other project, plaintextsports.com [1] (live sports scores in plain text with no ads or trackers so it loads instantly! I think the HN crowd would love it!). There's a weird line between marketing and advertising and self-promotion, where one is "ok", but the other is frowned upon. It's also a tale as old as time that the better marketed but technically inferior product wins out. (AC vs DC initially, Betamax vs VHS!) How much of success is being brazen enough to ignore those norms and shamelessly promote something? Should it be considered shameful to promote it in the first place?
In this case, being written in Rust is definitely a feature, as least when comparing tools! fx [2], a similar tool that made the front-page a couple months ago runs using Node, and I'm sure jless can handle bigger files and uses less memory (though admittedly I haven't actually verified this).
[1]: https://plaintextsports.com
[2]: https://news.ycombinator.com/item?id=29861043
You did make something useful. Don't feel bad about the title here. It's not like you're selling this as a rewrite of something that already exists with the only difference being that it's Rust. (And certainly not like the worse case of that where the selling point is "rewritten in Rust" but it actually has fewer features or is less user friendly than the original)
Content quality is key. The post "We're choosing Rust, and not Go, C++, or Node.js" got flagged a few hours ago after reaching the front page briefly: https://news.ycombinator.com/item?id=30465632 Although it reached some conclusions similar to those I might reach, it also (as another poster put it) "invited language flame wars" and contained some shoddy reasoning, which I and others did not appreciate.
I like reading posts touching on Rust which lead to thought-provoking and civil discussions — especially when the choice of Rust is germane — and I appreciate knowing that Rust is involved from the titling/marketing. Thanks for your good work!
I like reading posts touching on Rust which lead to thought-provoking and civil discussions — especially when the choice of Rust is germane — and I appreciate knowing that Rust is involved from the titling/marketing. Thanks for your good work!
This is a wonderful tool!
Exactly. I've submitted something written in Java, while something similar (and far inferior in features) written in Rust drew lot more attention
Look, I don't have a need for this application, but from the presentation of supported platforms:
> Linux
> Homebrew
> Arch Linux
> pacman -U jless
First, if you have to revert to homebrew as a package manager on gnu/linux you might as well tell the user to just use cargo directly, that way users only have to install the rust toolchain as opposed to the rust toolchain plus an alien package manger. The typical way would be to make cargo compile the thing, place in in ~/.local somewhere and add that path to PATH.
Second, "pacman -U ARG" installs from a file or from a URI. jless is neither. You have to properly package it before pacman will install from a file, which means you have to write a PKGBUILD file with some metadata and build instructions (about 20 lines) and call makepkg, which will then produce the package (a .tar.xz file if I'm not mistaken).
I suggest you first test the instructions you put on your website.
> Linux
> Homebrew
> Arch Linux
> pacman -U jless
First, if you have to revert to homebrew as a package manager on gnu/linux you might as well tell the user to just use cargo directly, that way users only have to install the rust toolchain as opposed to the rust toolchain plus an alien package manger. The typical way would be to make cargo compile the thing, place in in ~/.local somewhere and add that path to PATH.
Second, "pacman -U ARG" installs from a file or from a URI. jless is neither. You have to properly package it before pacman will install from a file, which means you have to write a PKGBUILD file with some metadata and build instructions (about 20 lines) and call makepkg, which will then produce the package (a .tar.xz file if I'm not mistaken).
I suggest you first test the instructions you put on your website.
Sorry! Someone already filed an issue about this [1], but I haven't had time to investigate exactly what is appropriate to put there. I don't use Linux, nor have I ever released and distributed open-source software before, so I'm just kinda guessing here -- other people have added the project to various package managers, not me.
Installing via Linux Homebrew is simply listed as an option because it's available as a Homebrew formula. And the option to install via cargo is also noted.
[1]: https://github.com/PaulJuliusMartinez/jless/issues/46
Installing via Linux Homebrew is simply listed as an option because it's available as a Homebrew formula. And the option to install via cargo is also noted.
[1]: https://github.com/PaulJuliusMartinez/jless/issues/46
As mentioned in this issue you should not give an install command since it's in the AUR. You can just mention it's available in the AUR and provide a link to the package instead: https://aur.archlinux.org/packages/jless
> you might as well tell the user to just use cargo directly
For Rust projects, there really is no need for more than this. It might take a bit longer, but it’s simple and easy.
For Rust projects, there really is no need for more than this. It might take a bit longer, but it’s simple and easy.
I really hope this trend doesn't continue, honestly. I shouldn't need the toolchain for a language that something was written in just to use that thing. It's very common with Go projects, too, but it's kind of a reversion back to the "./configure; make ; make install" days.
As far as I can tell, most of the package managers are just calling cargo under the covers anyway.
Only if they're building from scratch. Binary packages would have no need for cargo.
Most modern toolchains are robust, easy to use, and shared between many non-packages.
Go, Rust and Node.js cover a large portion of recent projects, and many others cheat with Docker or the like.
Go, Rust and Node.js cover a large portion of recent projects, and many others cheat with Docker or the like.
I find linuxbrew to be a welcome option since it's one of the most generic methods available.
It works on most distros and for most languages, instead of being tied to, say, rust or arch.
It works on most distros and for most languages, instead of being tied to, say, rust or arch.
I like Linuxbrew because I can install things without needing to mess with the system packages. I'm using it on my TrusNAS SCALE server to install things like fish and neovim. The stance of iXsystems has always been that TrueNAS is an appliance and you shouldn't touch the system packages, so I try not to apt install anything.
But, as said, for it to work you have to set up yet another package manager which will works against the systems package manager, leading to out of date packages and probably broken dependencies. Rust already has a working system that will put binaries to a standardized place that will properly integrate.
I know almost nothing about cargo since I don't do rust, but if it works as you say, integrating with the system's packages, you are more likely to end up with broken dependencies.
Brew keeps it's packages separate, so breaking is less likely.
Brew keeps it's packages separate, so breaking is less likely.
No, it won't. When rust "installs" an application, it will compile it as described in the cargo.toml, then put the resulting binary file in "~/.cargo/bin" (just looked it up to be sure). The user can then either execut from that directory directly or prefix PATH with it in his ~/.profile or similar files, making it available like any other program.
A separate package manager is not remotely needed for this and thus poses an unnecessary dependency and burden on users who didn't have homebrew installed. It integrates with the systems package manager in that it takes higher priority (well, or lower, depending on wether PATH was prepended or appended) during application lookup and does nothing else. Without looking at it I'd guess that homebrew does the same.
> I know almost nothing about cargo since I don't do rust
And you don't have to. Git clone, cargo install, add line to .profile (if not already there), done.
A separate package manager is not remotely needed for this and thus poses an unnecessary dependency and burden on users who didn't have homebrew installed. It integrates with the systems package manager in that it takes higher priority (well, or lower, depending on wether PATH was prepended or appended) during application lookup and does nothing else. Without looking at it I'd guess that homebrew does the same.
> I know almost nothing about cargo since I don't do rust
And you don't have to. Git clone, cargo install, add line to .profile (if not already there), done.
I don't see how any of that is better than brew. There is lots missing from your "no knowledge is needed" stance, like (1) how to install cargo (2) how to uninstall packages (3) how to upgrade them (4) how to install binaries without compiling.
For people who already have brew installed (since it works for much more than cargo) these things are already known.
For people who already have brew installed (since it works for much more than cargo) these things are already known.
I don't always use applications posted on HackerNews, but when I do, they're ones written in Rust.
Another contender is gron which does the same. It's written in golang instead of rust.
https://github.com/tomnomnom/gron
<pre>$ cat test.json | gron</pre>
https://github.com/tomnomnom/gron
<pre>$ cat test.json | gron</pre>
I have used Gron-- it's very useful and easy to learn and use.
I might be weird, but I find gron invaluable for figuring out what I need to pass to jq.
gron log.json | grep https
# see a json.log.entries[334].request.url
jq -r '.log.entries[] | .request.url' log.jsonExactly what I use gron for and my feature request would be to be able to do this from jless with one key. Currently it seems like jless doesn't even allow to select and copy it (on MacOS' terminal app).
This looks cool but HomeBrew for linux is a no go for me. Multiple system level package managers is asking for trouble.
Use cargo? It is user level
Yes, I can and will, but the point was "why homebrew for linux?".
Later I read the author was just not familiar with the Linux ecosystem which pretty much answered my question.
(Author here) Homebrew support was added entirely with macOS in mind, but Homebrew for Linux uses the same repository of formulas as Homebrew for macOS [1], so you get Linux support for free. I included Homebrew for Linux because it's an option, but I don't want it to be the only option.
I guess I should explicitly say in the documentation that help would be appreciated in adding support for other package managers. I definitely want jless available through the most standard avenues.
[1]: https://github.com/Homebrew/homebrew-core/blob/master/Formul...
I guess I should explicitly say in the documentation that help would be appreciated in adding support for other package managers. I definitely want jless available through the most standard avenues.
[1]: https://github.com/Homebrew/homebrew-core/blob/master/Formul...
Hi Author :-)
Please note that I am VERY much appreciating the application and effort, and this was not meant as criticism. I saw you mentioned you're not a Linux person which is cool - I get why the brew is there.
It's just that I never really understood why there even IS a homebrew for linux.
I'm pretty sure you'll find yourself with multo-distro repository presence soon enough since your app is useful indeed.
It's just that I never really understood why there even IS a homebrew for linux.
I'm pretty sure you'll find yourself with multo-distro repository presence soon enough since your app is useful indeed.
I've started using jless for interacting with things like the Kubelet API, it makes browsing through the response a lot easier when I don't know exactly what I'm looking for.
The ability to expand and collapse keys and moving around the sibling keys is great, the help was at the place where I expected it to be, ":h". I love this!
This does look like a useful tool. Especially since `jq | less` is a very common pattern for me.
Apologies if this might take things a little off-topic. But I can recall seeing "written in Rust" in the titles of quite a few HN posts. Is there any relevance to this? From my perspective, the utility of a given project/product could (or even should) be judged independently of the programming language that it was implemented in.
Apologies if this might take things a little off-topic. But I can recall seeing "written in Rust" in the titles of quite a few HN posts. Is there any relevance to this? From my perspective, the utility of a given project/product could (or even should) be judged independently of the programming language that it was implemented in.
As someone that has recently started learning Rust, I am certainly interested in looking at source for bigger projects than I've made. Getting a feel for patterns and examples of how to do certain things.
If your interest in jless is about its utility, you are right, language doesn't matter. If your interest in jless is looking at its code, I think language is relevant. And personally seeing it in the title let's me know without clicking that I might want to check out it's code later.
If your interest in jless is about its utility, you are right, language doesn't matter. If your interest in jless is looking at its code, I think language is relevant. And personally seeing it in the title let's me know without clicking that I might want to check out it's code later.
I think there's a legitimate interest in the popularity and adoption of Rust because a lot of people are curious to see if it will really stick.
So I for one find it interesting and it affects my sense of how it will play out.
So I for one find it interesting and it affects my sense of how it will play out.
Very true. The choice of a language isn't just driven by how appealing it is to oneself, but also how appealing it is to the broader population of developers. If you use a language that no one wants to work with then you're going to have a tough time getting people to want to contribute. You also end up limited on the third-party libraries that are available if you pick a language that isn't popular.
Feature suggestion: pressing some hotkey exits and prints the path that could be used in jq to select the node that was selected when the hotkey was pressed.
I'm sure it has a lot of corner cases as a feature, but that would be super-useful as companion tool to jq.
I'm sure it has a lot of corner cases as a feature, but that would be super-useful as companion tool to jq.
This is something I often use gron for. And having something like this as output from jless was my feature request the last time I saw this tool on HN.
I see it's added now, but it's not possible to select and copy. I'm also not sure about the keys, h or ? doesn't bring up any help text.
I see it's added now, but it's not possible to select and copy. I'm also not sure about the keys, h or ? doesn't bring up any help text.
Great tool thanks! I'll try to catch the livestream !
One thing that would be great to smoothen my use-case is a better resize support. I generally have a bunch of terminals on a screen, and switch to full screen when needed. Currently, the drawing region does not update.
One thing that would be great to smoothen my use-case is a better resize support. I generally have a bunch of terminals on a screen, and switch to full screen when needed. Currently, the drawing region does not update.
I usually just pipe jq output to less, but this is way nicer, thank you!
Hm, ctrl-d and ctrl-u don't work for me, for some reason (keybinds for scrolling in screen-halves), and scrolling and moving of cursor causes jittering, which is distracting.
I'm using lxterm.
Nice tool otherwise!
I'm using lxterm.
Nice tool otherwise!
Oops, sorry, I haven't actually made a new release with those commands yet. I'll need to have better discipline maintaining a separate `latest` branch for the website...
I use jq but it's not interactive like this
Rust, by the way
It seems like the new meta to get HN points.
"New software project (WRITTEN IN RUST) (COPS CALLED) (GONE WRONG)"
"New software project (WRITTEN IN RUST) (COPS CALLED) (GONE WRONG)"
It's not meaningless though. With all the checks and balances that the rust compiler enforces, you have a higher likelihood of having a correct and less buggy program.
In this context, "correct" and "less buggy" are referring specifically to memory safety issues which garbage collection can also solve. Sure, theoretically the C++ JS Engine that powers Postman could maybe have a memory issue when loading up JSON. Until that actually happens, switching to this for a subset of the tasks Postman (or the Chrome dev tools) accomplishes is a waste of time.
And community engagement compounds — people like contributing to rust projects, so we can trust the project will continue to grow, so we'll use it, so more people will contribute, etc etc.
This holds even if the original reason they enjoyed contributing isn't a good reason!
This holds even if the original reason they enjoyed contributing isn't a good reason!
Nice job! Looks useful
I love it!
[1] https://news.ycombinator.com/item?id=30273940