Comment by mikemcquaid
1 month ago
Today, I’m proud to announce Homebrew 7.0.0. The most significant changes since 6.0.0 are faster installations and upgrades, stronger sandboxing, a native macOS app, built-in vulnerability checks and an advisory database, the end of macOS 10.15 support and Intel Macs moving to Tier 3 (announced last year).
Literally just upgraded before seeing this post; I had 31 outdated packages and the first thing I saw was how blazing fast it was! I looked online to see if something changed and saw this post.
Speed was my biggest complaint about brew, so I'm glad to cross that one off my list of things I don't like about brew.
Thank you for your hard work BTW, brew's been a lifesaver on macOS and immutable distros.
Glad to hear it. A lot of time and energy has gone into performance work so glad that’s noticeable! Thanks for the kid words too <3
It is Rust now?
It's still in ruby, although I see the new GUI is in swift: https://github.com/homebrew
Rewriting a program in Rust (specifically) really only makes sense for a few reasons:
1) the existing implementation is in an unsafe, cumbersome language (C, C++).
2) the existing implementation language is too slow and that slowness cannot be worked around.
3) the implementation is enormous, in a dynamic language and you desperately need stricter types. But this doesn't really favor Rust specifically.
1 doesn't apply because Ruby is garbage collected. It's doubtful 2 applies just given what homebrew does: the long pole is always going to be I/O. The performance improvements in version 7 seem to mostly be due to doing more concurrently. I highly doubt the Ruby-ness gets meaningfully in the way.
2 replies →
Thank you for Linux Homebrew! It works so damn well.
For me the distro package manager is for system packages, Homebrew and Flatpak for the user facing apps.
Where do you draw the line between system packages and user facing apps? Some software defies such an easy categorization. If your default install doesn't come with docker and you install docker later for development, does that make docker a user-facing app? What about language toolchains like golang, rust, npm, etc?
> Where do you draw the line between system packages and user facing apps?
If it works in Homebrew, I almost always pick Homebrew. :) I have a pretty good feeling for what works since for the past few years I've mostly used an atomic distro (Aurora, based on Universal Blue, based on Fedora). It just comes naturally for me on Fedora too.
I've found that this way you can get many of the stability pros of using an atomic distro even on a non-atomic one.
5 replies →
It's an interesting question on Linux. On macOS entire toolchains would be fair game. I just ran `brew install colima`, `brew install llvm`, etc.
But clearly anything that would conflict with distro-specific opinionated decisions is out. Or DE-specific opinionated decisions. Maybe a good rule is "anything that would be useful simutaneously on all *nix".
2 replies →
I don't understand the distinction you use here.
Then again I use versioned AppDirs on Linux since +20 years anyway, so I am not really into any arbitrary disctinction random linux distributions try to push down onto the (downstream) userbase. Besides, if you compile from source, why would you want to rely on the distribution package manager to begin with?
None of them allow for versioned AppDirs by default as far as I know; NixOS uses a hashed name, so that is the only exception I can think of (and GoboLinux of course), but as far as I know if you are on e. g. a debian system, you can not use it for a versioned AppDir layout.
> NixOS uses a hashed name, so that is the only exception I can think of (and GoboLinux of course)
Also Guix, which is inspired by Nix. Don’t know about AppDir support, though. Are AppDirs more of a general concept or a formalised standard? In what capacity are you using them?
1 reply →
> I don't understand the distinction you use here.
Distinction: https://news.ycombinator.com/item?id=49683258
I use "dnf" to upgrade my system and "flatpak update" and "brew upgrade" to upgrade the apps I've installed.
An app like VirtualBox does not install using Flatpak or Homebrew, so I would use dnf for that. It's usually an app or two that doesn't work via Flatpak/Homebrew/AppImage that I need to install using dnf.
Same, for me it made it possible for me to work on Linux with teammates on Mac with very little messing around of the setup scripts.
On Linux I use mise to install CLI tools
I don't know what I would do without brew on my Macs. Thank you and everyone who contributes!
Silly question - but how do you apply the cooldown to brew itself ?
I would think this is one of the most critical dependency that you would not want to get right away at let it rest for a couple of days
You can’t, by design. We instead apply if for you on upstream packages from NPM, PyPi, etc.
Our model is very different to those where cooldowns exist and make sense. As-is if would just delay security updates too.
Congrats and thank you to you and your team for maintaining critical infrastructure we all take for granted.
I think at one point you said you’re working on a rust rewrite? Is that still in the cards?
I tried it. It ended up being slower on most non-synthetic benchmarks (like repeatedly installing the same thing with warm caches).
The lessons learned were instead used to make the Ruby frontend much faster.
I don't know anything about homebrew, but have a question ...
I see some parallels between homebrew and Gradle ... for the longest time Gradle was using Groovy for build scripts. The Gradle / Groovy build script DSL was a little too magic and dynamically typed. It looked cute, but led to issues in developer UX (awful stack traces), tooling (documentation and autocomplete), robustness, and performance.
There are other reasons why Gradle is moving away from Groovy. I suspect that the number of people that use and know Groovy is steadily declining. Declarative Gradle, which is the future, is not Turing complete.
I can't help but notice the parallels between Gradle / Groovy and Homebrew / Ruby: using a dynamically typed Ruby DSL with Turing completeness like the olden Gradle ways, and Ruby is declining in popularity like Groovy.
I would have to imagine at some point, the people who know Ruby well enough to create / debug formulae will dwindle. What are the plans?
3 replies →
https://news.ycombinator.com/item?id=42535217
They experimented with it but ultimately decided to focus on perf with their existing ruby codebase.
https://github.com/Homebrew/brew/issues/7755#issuecomment-51...
would you please share what amount of the new dev (work done on brew) is AI/LLM-assisted. this major version bump was very quick to arrive compared to when v6 got released?
Can’t speak for others but a lot of my work. I review it all locally first. The flow feels a lot like reviewing human PRs locally.
https://github.com/MikeMcQuaid/AgentIDE
I actually wrote my own “Agent IDE” to make this prompt/review/push flow easier.
Thank you, very insightful. TBH, expected an actual flow of nonsense and suspicion meanwhile, but a daly later there is still none, perhaps the general sentiment already shifted enough. It also confirms the notion that the credibility of the author is more important than the credibility of the means to develop. Also, of course, we're all going to move to newer brew sooner or later, so this all effort is much appreciated.
Looks cool! Building.
`The macOS deployment target is set to 27.0, but the range of supported ....`
Golden Gate AAAAAARRRGGGHHHHHH
Just another few days, right? :)
Definitely notice the speed increase. Thank you for Homebrew. It's one thing that makes macOS bearable.
Was issue with upgrade running out of disk space fixed?
[dead]