
Common *nix commands written in Rust - lowonkarma
https://gcollazo.com/common-nix-commands-written-in-rust/
======
burfog
From the ls replacement: "Why spend your time squinting at black and white
text?"

Uh, because squinting at blue-on-black text is much more difficult. Human eyes
focus best at yellow-green, they see that as brightest, and they don't even
have long-wavelength (blue) receptors in the fovea.

I also looked at the alternatives to ps, top, cat, find, and du.

My overall feeling is that these are really not like UNIX tools at all. They
are not very scriptable. Output is full of Unicode, color, column dividers,
headers, underlining, and pagination. Values are in so-called "human readable"
form, like "1.4M" instead of 1474560 or whatever it may be, which is a real
pain for scripting.

I also notice some features that seem out of place to me, a long-time UNIX
user. The tools waste space on displaying things related to git, docker, and
network connections. I would expect the proper tools to be more like "git ls",
"docker ls", "docker ps", and "netstat -p". (for those ones that don't
actually exist, take that as a suggestion for a coding project) Not all the
world is devops on a web site.

~~~
ReactiveJelly
My distro's ls already does coloring by default. It turns it off somehow if it
detects the output is a pipe, so that "ls | less" still works. It also turns
off multi-column in that case, so "ls | wc -l" counts directory entries.

~~~
boulos
[https://linux.die.net/man/3/isatty](https://linux.die.net/man/3/isatty) :)

------
platinumrad
There are sometimes good reasons, usually related to features although
sometimes related to performance, to prefer newer utilities like ripgrep over
older ones like grep. Implementation language is not one of them.

~~~
throwaway_pdp09
I came here to ask, thought not outright say, what is it with all the "... in
rust" stuff that keeps getting posted. It's starting to feel more like a
marketing exercise than anything actually software related (happy to be
corrected on this though).

~~~
infraredcabbage
Consider this. If a program is written in Python, and becomes popular, it is
usually a matter of time before it gets rewritten in, and replaced by an
implementation in a faster language.

There are fast implementations (C) and there are somewhat safe implementations
(Python, Java, ...). If I were to place Rust in this hierarcy - it is both
fast AND safe, and there's rarely a good reason to replace it, so you've
software that's already at the top of the hierarcy. This means that the
particular implementation is likely to be the one that doesn't get replaced.

"...in Rust" has a lot of implications other than being an exercise in
marketing.

~~~
johnklos
Except Rust isn't a direct replacement for c. Rust's system requirements are
perhaps acceptable for what'll be normal in computers five years from now.

We don't need to re-stratify development so that only people with expensive
computers with > 4 gigs of memory can compile what they run.

~~~
zlynx
You're exaggerating for effect, I assume. Rust compile does not require that
much RAM.

Now, by default the "cargo" build uses all CPU threads, so if you have a 32
core Threadripper then yes, running 64 simultaneous "rustc" compiles will use
6 or 7 gigabytes.

~~~
hu3
Last I checked Rust needed more than 4GB of RAM to compile itself.

That's one of the reasons it was rejected in OpenBSD:
[https://marc.info/?l=openbsd-
misc&m=151233345723889&w=2](https://marc.info/?l=openbsd-
misc&m=151233345723889&w=2)

~~~
monocasa
clang needs more than 4GB to compile itself too.

------
merlinsbrain
This isn’t too compelling a story on its own, I’m assuming this is someone who
wrote a collection for themselves and made it public on their blog.

Glad they wrote their collection, but not something I’m excited about.

In general I’d love to hear “this was better in Rust because of X, Y and Z and
the tradeoffs I had to make were A, B and C”.

But again, this isn’t on the author to do, I’m pretty sure I can find other
articles on the internet that talk to that.

Edit: most of the READMEs of the projects look pretty good about that on a
quick skim.

------
harikb
What I would like to see is something like Hadoop, Kafka, Spark rewritten in
Rust. Something that will fundamentally change the landscape. Rewriting these
Unix cli is only good learning experience

~~~
pdimitar
Maybe, but consider that security vulnerabilities have been found in SSH and
`sudo` / `su`, several times the last few years (and they are not the only
UNIX tools, it was just the noisiest news about such vulnerabilities).

Any new programming tech that avoids my SSHD letting anyone get in because of
this or that is very welcome by me.

There's Sonic, which is a searching software, although not on the level of
ElasticSearch. People are working hard to bring more safety to widely used
technologies, every day, we just don't hear much about it.

------
nailer
nushell is a better idea though - structured output, no text scraping.

And it's Rust! [https://www.nushell.sh/](https://www.nushell.sh/)

~~~
gigatexal
Yes this I think should be the future direction shells go

------
nine_k
It's a nice collection of common CLI utilities that make one's life a bit more
comfortable.

The poster is not the author, but the collector.

