Navi- an interactive cheatsheet tool for the command line(github.com)
github.com
Navi- an interactive cheatsheet tool for the command line
https://github.com/denisidoro/navi
16 comments
How does this stack up versus cheat.sh ? I really should be making use of one of these and I would prefer to learn the most useful.
Navi can be a wrapper for a lot of other cheat sheet tools including cheat.sh and tldr besides handling your own sets of cheat sheets.
https://github.com/denisidoro/navi/blob/master/docs/cheatshe...
also look at cheat. combines community maintained and custom cheat sheets configured as simple text files.
https://github.com/cheat/cheat
https://github.com/cheat/cheat
It’s quite insane the amount of nice tooling people have been building thanks to Rust. I’m wondering why is it that Rust transitioned us to a new era for open source. My bet is the package manager.
As far as I'm concerned, my preference when learning a new language is to build (in order of preference):
* a CLI tool
* a backend service
* a plugin to an existing tool
* an HTTP API / web app
You will note that a basic CLI tool requires nothing but arg parsing to get started, no complicated library or abstraction layer, while as you advance in the list above, you will most certainly use more libs and less of the raw language constructs.
Also, in the case of Rust and other compiled languages, ease of distribution as a binary rather than a package or some form of arbitrarily complicated installation method certainly helps.
YMMV of course but this is my approach and maybe it explains a bit of the trend you're wondering about.
* a CLI tool
* a backend service
* a plugin to an existing tool
* an HTTP API / web app
You will note that a basic CLI tool requires nothing but arg parsing to get started, no complicated library or abstraction layer, while as you advance in the list above, you will most certainly use more libs and less of the raw language constructs.
Also, in the case of Rust and other compiled languages, ease of distribution as a binary rather than a package or some form of arbitrarily complicated installation method certainly helps.
YMMV of course but this is my approach and maybe it explains a bit of the trend you're wondering about.
I think most of the same is true for Go. These languages are perfect for making CLI/TUI tools
Absolutely. My initial comment was using Rust as an example only. It also applies to Go.
But not to JS or Python, to be clear.
But not to JS or Python, to be clear.
I wouldn't say it's a new era of open source, there's nothing novel about licensing from rust. But from a tool perspective both rust and golang support easy static binary creation and IMHO that's why you see both of them being popular with modern CLI tools.
Gone are the days of packaging up distro-specific binaries, or worse yet depending on some system installed script interpreter (and all the myriad of ways it can be broken or out of date on your user's machines). Now you just download a single executable, put it in your path, and you're done. It will always work--today, tomorrow, ten years from now. It's so easy and reproducible you can even just commit the tools into your source repo if you want.
Gone are the days of packaging up distro-specific binaries, or worse yet depending on some system installed script interpreter (and all the myriad of ways it can be broken or out of date on your user's machines). Now you just download a single executable, put it in your path, and you're done. It will always work--today, tomorrow, ten years from now. It's so easy and reproducible you can even just commit the tools into your source repo if you want.
> But from a tool perspective both rust and golang support easy static binary creation […]
Honest question: As someone who knows C++ and CMake, what Rust and Go do to make it easier?
Honest question: As someone who knows C++ and CMake, what Rust and Go do to make it easier?
Disclaimer: I don't know C++ (well)/CMake(at all). I'm guessing the tooling for creating static binaries is only marginally better.
At least for rust (I'm not as familiar with Go), it brings super easy project setup and library inclusion.
E.g. for creating a project and running it:
> cargo new my-cli > cd my-cli > cargo run
And then all I need to do is add structopt to the cargo.toml file to bring in a command line parser with hygienic macros.
Edit: they also do static linking by default :EndEdit
‐---------------------
But what it really makes easier is not needing to worry about memory safety. C++ is good at making static binaries, even if it might be slightly more fiddly.
So it's more like the static binary is the advantage over scripted languages, and memory safety is the advantage over c++.
I would never attempt a tool in c++ now that I know Rust.
At least for rust (I'm not as familiar with Go), it brings super easy project setup and library inclusion.
E.g. for creating a project and running it:
> cargo new my-cli > cd my-cli > cargo run
And then all I need to do is add structopt to the cargo.toml file to bring in a command line parser with hygienic macros.
Edit: they also do static linking by default :EndEdit
‐---------------------
But what it really makes easier is not needing to worry about memory safety. C++ is good at making static binaries, even if it might be slightly more fiddly.
So it's more like the static binary is the advantage over scripted languages, and memory safety is the advantage over c++.
I would never attempt a tool in c++ now that I know Rust.
As someone who has struggled with cmake for years, the answer can be found in setting up a simple Rust project in a few minutes: it will just work out of the box. The default config is all you need, and you won't have to do back and forths to understand other projects setups (unless they're massive). You will easily import and use dependencies you need, even small edge-cases can easily be a line in your config file.
It happens by default, more or less.
Honestly, I think part of this perception is the fact that things developed in Rust are more likely to advertise themselves as such. For example, I know that micro text editor is developed in Go only because I checked. I have no need to know this as an end-user, but many Rust-based projects seem quite eager to highlight that.
I have a feeling that advertising that it's Rust instantly means:
* you can reuse (parts of?) it in your project easily
* it will be fast
* you can contribute to it easily
* you can reuse (parts of?) it in your project easily
* it will be fast
* you can contribute to it easily
[deleted]
It seems to be becoming the new Go.