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).
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!
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.
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.
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
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.
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.
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.
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.
Exactly 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).
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.
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.
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.
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.
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.
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.
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.
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.
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...
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!
[1] https://news.ycombinator.com/item?id=30273940