I'm honestly wondering when will we have the whole coreutils rewritten in Rust.
Show HN: A simple, fast and user-friendly alternative to find, written in Rust
141–150 of 225 posts
Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust
#142Earlier quoted context omitted.
I appreciate all these new incarnations of old school tools but end up sticking with the basics regardless. When I'm sshing into a box to figure out whats going on, my toolset is mostly limited to top, find, xargs, awk, grep, df, du etc. Even local development now, I'm mostly debugging on a docker container running alpine or ubuntu. Knowing the right incantations is useful in that context and keeps me from installing…
What surprises me is that even after 25 years of the Internet, we cannot bring in new tools into our environment (be it a remote box I ssh into or a trimmed down docker image) on the fly. The popular package management tools rely heavily on FHS and like to install stuff into directories that require root permission. Imagine if there was a tool that could download binaries of modern tools from a certain repo and insta…
sudo chown -R user:user /usr, that’s what you effectively suggest. Also convince tool makers to provide ppas.
Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust
#143Earlier quoted context omitted.
I just tried ripgrep and it's faster and I think I like the output better :)
It is definitely faster. The ripgrep author did extremely extensive benchmarking to a lot of tools. For the most common usecase check out this section, but the rest of the article is very much worth a read as well: http://blog.burntsushi.net/ripgrep/#subtitles-literal
The HN thread about it had a good discussion between the ag and ripgrep authors. https://news.ycombinator.com/item?id=12567328
Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust
#144It would be nice to have a collection of modern/faster/saner alternatives to common unix tools and such utilities (made in rust or not) that becomes standard -- or at least easily installable in linux distros and OS X. Not for replacing those tools, but for supplementing them. Thinking of stuff like fd and: ripgrep: https://github.com/BurntSushi/ripgrep (grep/ag alt) xsv: https://github.com/BurntSushi/xsv (csv tool)…
It would be even nicer to have an opensource project that pushes a set of these tools, that then can get picked up by the distros such that in 5 year you can expect these all to be included at a reasonable version such that you do not have to install them by hand on each machine that you land on. On the other hand, you may want to keep some smart dotfiles around that installs them in ~/bin
That's the kind of idea that lead to Joey Hess's "moreutils".
Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust
#145Earlier quoted context omitted.
Ideally it would be nice if common utils were redeveloped to have optimisations that weren’t thought of or available back in the day
That's basically what's happening. AFAIK, ack kinda started it all by observing, "hey, we frequently have very large directories/files that we don't actually want to search, so let's not by default." Depending on what you're searching, that can be a huge optimization! Tools like `git grep` and the silver searcher took it a step further and actually used your specific configuration for which files were relevant or not…
>”hey, we frequently have very large directories/files that we don't actually want to search, so let's not by default”
>Was this a thing back when the BSD and GNU greps were being developed? Was it common for people to have huge directory trees (e.g., `node_modules` or `.git`) lying around that were causing significant search slow downs? Not sure,
Sure, actually. It was called “build” and it was moved out of source code hierarchy to not interfere with tools. Pretty clever, and you don’t have to patch every tool each time new build-path appears. This should lead us to some conclusion, but I cannot figure out which. Do you?
Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust
#146It would be nice to have a collection of modern/faster/saner alternatives to common unix tools and such utilities (made in rust or not) that becomes standard -- or at least easily installable in linux distros and OS X. Not for replacing those tools, but for supplementing them. Thinking of stuff like fd and: ripgrep: https://github.com/BurntSushi/ripgrep (grep/ag alt) xsv: https://github.com/BurntSushi/xsv (csv tool)…
Maybe something like "BusyBox": a single multi-use executable, would help with adoption. If you like one executable you get the whole useful package.
Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust
#147Will we ever be able to promote a tool without talking about the programming language it is implemented in?
Rust is somewhat of a special case: I bet some people mention their software is written in Rust just to avoid a bunch of comments proposing to rewrite it in Rust,
Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust
#148hey david, you can omit the 'static lifetime in the root directory string declarations if you want!
Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust
#149I'm honestly wondering when will we have the whole coreutils rewritten in Rust.
https://github.com/uutils/coreutils is a long way along.
Re: Show HN: A simple, fast and user-friendly alternative to find, written in Rust
#150Earlier quoted context omitted.
The fact that Rust is used is uninteresting, considering there's nothing special about it as it pertains to the other advertised features. "Bullshit" might be strong, but "trivia relevant only to a person interested in fomenting language flamewars" isn't a stretch.
> The fact that Rust is used is uninteresting, considering there's nothing special about it as it pertains to the other advertised features. Considering the fact that a programming language's appeal is directly influenced by the size and accomplishments of its community, I'd say it's relevant. A high level, systems programming, relative new language is used to write software that outperforms the default tools. That's…
>A high level, systems programming, relative new language is used to write software that outperforms the default tools.
It does stretch “the alternative” meaning on it and only then outperforms, actually. But it is not a tool alternative, it is alternative to few use cases, which could be improved by contributing to original projects, but instead they do blind fragmentation. Efforts spent meaninglessly and destructively from the unix community pov.
Take a good tool, call it slow, incompatibly rewrite one option optimized to hell, present as an alternative in rust, take rust hype, cv points, attention, hate from those who understand what is done. Take it all, be a man.