Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Common *nix commands written in Rust

gcollazo.com

Post reply on HN
Print view View original

11–20 of 56 posts

Re: Common *nix commands written in Rust

#11

Post by ReactiveJelly »

burfog wrote: post #8

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…

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.

Re: Common *nix commands written in Rust

#12

Post by infraredcabbage »

throwaway_pdp09 wrote: post #3
platinumrad wrote: post #2

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.

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

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.

Re: Common *nix commands written in Rust

#13

Post by boulos »

ReactiveJelly wrote: post #11
burfog wrote: post #8

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…

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.

https://linux.die.net/man/3/isatty :)

Re: Common *nix commands written in Rust

#14

Post by johnny22 »

mhh__ wrote: post #9
monocasa wrote: post #4

Earlier quoted context omitted.

I think it's just that Rust brings a fairly new set of semantics to system code (memory safe, but no GC), and people are pretty excited to rethink large parts of the software stack we all depend on.

That's but rust has been a known quantity for 5(?) years at least now?

known to who though? I just told a long time C++ dev about Rust during a discussion about programming languages. He'd never heard of it before, and was quite interested.

There are still quite a few folks out there who don't know about Rust, Go, or anything else that's gotten popular over the past few years here.

Re: Common *nix commands written in Rust

#16

Post by Myrmornis »

burfog wrote: post #8

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…

That's not fair. They typically turn off visual adornments when the output is not a tty, thus automatically supporting consumption by both human eyes and scripts.

Re: Common *nix commands written in Rust

#17

Post by platinumrad »

infraredcabbage wrote: post #12
throwaway_pdp09 wrote: post #3

Earlier quoted context omitted.

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

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 softwa…

So why not write "fast and safe implementations of popular command line utilities" rather than focusing on the implementation language? If there were a safe and fast implementation of, for example, find in Ada why should it be excluded from this list?

Re: Common *nix commands written in Rust

#18

Post by johnklos »

infraredcabbage wrote: post #12
throwaway_pdp09 wrote: post #3

Earlier quoted context omitted.

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

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 softwa…

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.

Re: Common *nix commands written in Rust

#20

Post by zlynx »

johnklos wrote: post #18
infraredcabbage wrote: post #12

Earlier quoted context omitted.

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 softwa…

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.

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.

Post reply on HN