111–120 of 168 posts
I wish there was a decent package manager on windows too. Chocolates used to be OK but I often find outdated packages and they keep breaking the syntax of existing scripts regularly (like by making almost all packages now require the flag --allowemptychecksum). I don't know why it never really took off. This is such a practical way to setup a machine.
Earlier quoted context omitted.
> Why is telemetry collected through Google? No-one else provides anywhere near the same scale for free. We have over a million monthly active users and every other solution we tried (including FOSS ones) either fell over at that load or we couldn't find anyone willing to provide hosting for us. We don't send any personally identifiable information to Google. You are tracked by a randomly generated UUID (which you ca…
> We don't send any personally identifiable information to Google. Yes, you do. While you use[1] the "Anonymize IP" option, a packet is still sent from the user's IP. Google's business model includes gathering as much data as possible so it's foolish to think that they are throwing data away in this situation. You may disagree and trust Google to honor the "Anonymize IP" option, but trust is not transitive so you sho…
> Yes, you do
PII is a term of the art which the GP is using in its standard sense and you are not. https://en.wikipedia.org/wiki/Personally_identifiable_inform...
(This is independent of the deontolic status of your comment.)
Youtube-dl at #18 is hilariously telling, although to be fair it's great for archiving clips (from all sorts of sites, not just YouTube) that may get deleted due to all sorts of reasons.
Earlier quoted context omitted.
> How often do you handle files large enough to observe a difference between grep, ack, ag and rg ? > I'm willing to bet that most people, even in the subset who use grep "a lot" (defining "a lot"...), wouldn't see a significant improvement. Daily, but not for the reasons that I think you're thinking. I work in Python a lot, which means there is typically a virtualenv in the tree somewhere, sometimes more than one. T…
Possibly redundant information, but still: ag has those same features. I see lots of reasons to choose rg/ag over grep, but none yet to choose rg over ag.
Earlier quoted context omitted.
> How often do you handle files large enough to observe a difference between grep, ack, ag and rg ? > I'm willing to bet that most people, even in the subset who use grep "a lot" (defining "a lot"...), wouldn't see a significant improvement. Daily, but not for the reasons that I think you're thinking. I work in Python a lot, which means there is typically a virtualenv in the tree somewhere, sometimes more than one. T…
Possibly redundant information, but still: ag has those same features. I see lots of reasons to choose rg/ag over grep, but none yet to choose rg over ag.
But yes, the feature sets are very similar.
Earlier quoted context omitted.
ripgrep's command line is `rg`, and it's much faster. When I first installed it I aliased `ag` to it to easy the transition.
How often do you handle files large enough to observe a difference between grep, ack, ag and rg ? I'm willing to bet (and happy to lose) that most people, even in the subset who use grep "a lot" (defining "a lot"...), wouldn't see a significant improvement. They are people (I'm betting fewer) who need speed above all other concerns, and those people already make it to the top 1000.
Before I wrote ripgrep, I was a grep user. I hadn't migrated to ack or the silver searcher because I didn't see the need. (Sound familiar? :P) In my $HOME/bin, I had grepf:
#!/bin/sh
find ./ -type f -wholename "$1" -print0 | xargs -0 grep -nHI "$2"
#!/bin/bash
first=$1
shift
grep -nrHIF "$first" $@
ripgrep didn't begin life as something that I intended to release as its own project. It began life as a way to test the performance of Rust's regex engine under similar work-loads as the regex engine in GNU grep. In other words, it was a benchmark that I used. (In fact, I used it quite a bit to reduce per-match overhead inside the regex engine. The second commit in ripgrep says, "beating 'grep -E' on some things.") I didn't really start to convert it to a tool that other people could use until I realized that it was actually as fast---or faster---than GNU grep. That, plus I was bored in an airport. :-)
A lot of people are happy with their tools that are good enough. I know I was. Has my life been dramatically changed by using ripgrep? No, not really. But I do like using it over my previous tools. It's a minor quality of life thing. It turns out, a lot of people care about minor quality of life things!
But yeah, I hear roughly the same sentiments that you say from a lot of people. All it really comes down to is different strokes and different common workloads that magnify the improvements in the tool.
I'm surprised that ripgrep is so low, at #227. I've been using it instead of grep the last few months and I could never go back. Check it out if you haven't! Here is the repo and a technical breakdown by the author: https://github.com/BurntSushi/ripgrep http://blog.burntsushi.net/ripgrep/
I hate that ripgrep won't let you specify an arbitrary list of filename extensions to search. You have to do some voodoo to get it to only search .foo files. With ag it's as simple as -G foo. It's better than ag in a lot of ways, but there are little pain points like that which make me shift back and forth between tools.