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/
Is it better than ack-grep? I've been using ack-grep for years, seems fine.
HomeBrew Analytics – top 1000 packages installed over last year
131–140 of 168 posts
Re: HomeBrew Analytics – top 1000 packages installed over last year
#132Earlier quoted context omitted.
First, thank you for your reply and your work. Second, I include myself in the users of ripgrep (and the silver searcher before), I also dislike the slight waiting time when I have a better alternative. Third, I'd like one those to be a default package in Debian.
:-) > Third, I'd like one those to be a default package in Debian. Yeah, I'd love that too! I know there have been people pushing on this, but AFAIK, it's stalled on "how do we package Rust applications in Debian." (I don't use Debian and I'm not terribly familiar with their policies, so I'm not really familiar with the details.)
Re: HomeBrew Analytics – top 1000 packages installed over last year
#133Earlier quoted context omitted.
:-) > Third, I'd like one those to be a default package in Debian. Yeah, I'd love that too! I know there have been people pushing on this, but AFAIK, it's stalled on "how do we package Rust applications in Debian." (I don't use Debian and I'm not terribly familiar with their policies, so I'm not really familiar with the details.)
Rustc and Cargo are packaged for Debian; both are Rust applications. That shouldn't be the holdup.
Re: HomeBrew Analytics – top 1000 packages installed over last year
#134Earlier quoted context omitted.
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.
Well, the main would be speed, possibly even stability, (Rust vs C), but if you're not after those, there's little reason to choose rg over ag. On the other hand, speed is also the primary reason to go with ag over ack, so the question is, why not go with the fastest alternative?
Re: HomeBrew Analytics – top 1000 packages installed over last year
#135Earlier quoted context omitted.
Is it better than ack-grep? I've been using ack-grep for years, seems fine.
Speed is probably the main difference. I can't find direct comparisons, but ag is touted as faster than ack, and ripgrep as faster than ag.
My blog post linked elsewhere goes into more detail, although I left out ack because it was too slow.
Re: HomeBrew Analytics – top 1000 packages installed over last year
#136I'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/
Is it better than ack-grep? I've been using ack-grep for years, seems fine.
> Notably absent from this list is ack. We don’t benchmark it here because it is outrageously slow. Even on the simplest benchmark (a literal in the Linux kernel repository), ack is around two orders of magnitude slower than ripgrep. It’s just not worth it.
Re: HomeBrew Analytics – top 1000 packages installed over last year
#137I'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/
Re: HomeBrew Analytics – top 1000 packages installed over last year
#138MySQL. Still more popular than Postgres.
Many people on MacOS use Postgres.app for their PostgreSQL needs. http://postgresapp.com
Re: HomeBrew Analytics – top 1000 packages installed over last year
#139Earlier quoted context omitted.
> as justification for removing an unused formula This does not, in my mind, help the case at all. This culture of deletion makes no real sense to me; something not being used for a month or a year doesn't mean it's not being used at all. What's the real cost of just leaving those formula around? A slight problem with it not working immediately when it is used? At least then it can be fixed, instead of seeing the "No…
> At least then it can be fixed, instead of seeing the "No formula found" text. You don't see that text but instead text indicating the formula has been deleted. > The culture of deletion surrounding the long tail of digital artifacts just doesn't make any sense. They will be preserved in the Git history for as long as we continue to use Git. Both the above comments make it seem like you've not really done any resear…
Anyways. Having done my research:
> You don't see that text but instead text indicating the formula has been deleted.
If, and only if, you know the exact name of the package. If you do a search, you get the "no formula found". If you attempt to use the braumeister.org web site, it also will not show up unless you explicitly craft the recipe URL.
> They will be preserved in the Git history for as long as we continue to use Git.
How does one go back into git history and revive deleted formula, given how automated the entire process is around ensuring the most recent version of brew is always in use? By your "deleted" help docs, I infer that it comes down to creating your own cask?
The one example I came across quickly is "abi_compliance_checker'. It was deleted because it requires GCC 4.7. Yet Homebrew is still quite capable of installing and using gcc@4.7. Not that it was broken in a recent build. Not that it was a major maintenance burden - the updates for years consisted of version updates.
This isn't something I need, but it's a great (and quickly found) example of seemingly arbitrary deletion of an otherwise active project.
Re: HomeBrew Analytics – top 1000 packages installed over last year
#140Earlier quoted context omitted.
First of all, let me say I appreciate your response and your work on Homebrew, a great piece of software, and quite a blessing for Mac users. > No-one else provides anywhere near the same scale for free. That's a bit naive. Google is not a charity and provides that service by making a profit out of user data. > We don't send any personally identifiable information to Google. You are tracked by a randomly generated UU…
> That's a bit naive. Google is not a charity and provides that service by making a profit out of user data. So what if they make profit -- they provide a fantastic service that actually works well, and it allows homebrew (and many other systems) to continue to provide it's services for free.