[pxc]

It is really coll that Homebrew provides a comprehensive enough JSON API to let people build on Homebrew in useful ways without directly running Ruby, despite everything being built in a Ruby DSL. That really does seem like a "best of both worlds" deal, and it's cool that alternative clients can take advantage of that.

I didn't know about the pending, official Rust frontend! That's very interesting.

[SOLAR_FIELDS]

Wow they are finally getting away from Ruby? Awesome. The speed will be a nice boon

[petcat]

Yeah I don't know why people are saying that speed doesn't matter. I use Homebrew and it is slow.

It's like yum vs apt in the Linux world. APT (C++) is fast and yum (Python) was slow. Both work fine, but yum would just add a few seconds, or a minute, of little frustrations multiple times a day. It adds up. They finally fixed it with dnf (C++) and now yum is deprecated.

Glad to hear a Rust rewrite is coming to Homebrew soon.

[kelvie]

One of the reasons I switched to arch from debian based distros was precisely how much faster pacman was compared to APT -- system updates shouldn't take over half an hour when I have a (multi)gigabit connection and an SSD.

It was mostly precipitated by when containers came in and I was honestly shocked at how fast apk installs packages on alpine compared to my Ubuntu boxes (using apt)

[akdev1l]

pacman is faster simply because it does less things and it supports less use cases.

For example pacman does not need to validate the system for partial upgrades because those are unsupported on Arch and if the system is borked then it’s yours to fix.

[pxc]

Less charitably, pacman is fast because it's wrong. The dependency resolver is wrong; it fails to find correct answers to dependency resolution problems even when correct answers are available.

[novok]

Ruby doesn't have to be the slow part, bazel uses starlark which is mostly python and it's very fast.

[SlightlyLeftPad]

Bazel has other problems

[ukuina]

Could you elaborate?

[SlightlyLeftPad]

Sure,

* it’s purpose built for mega-sized monorepo models like Google (the same company that created it)

* it’s not at all beginner friendly, it’s complex mishmash of three separate constructs in their own right (build files, workspace setup, starlark), which makes it slow to ramp new engineers on.

* even simple projects require a ton of setup

* requires dedicated remote cache to be performant, which is also not trivial to configure

* requires deep bazel knowledge to troubleshoot through its verbose unclear error logs.

Because of all that, it’s extremely painful to use for anything small/medium in scale.

[akdev1l]

yum was slow not because of python but because of the algorithm used to solve dependencies

Anyway the python program would call into libsolv which is implemented in C.

dnf5 is much faster but the authors of the program credit the algorithmic changes and not because it is written in C++

dnf < 5 was still performing similarly to yum (and it was also implemented in python)

[wavemode]

> dnf < 5 was still performing similarly to yum (and it was also implemented in python)

I'm perhaps not properly understanding your comment. If the algorithmic changes were responsible for the improved speed, why did the Python version of dnf perform similarly to yum?

[akdev1l]

Because dnf4 used the same dependency resolution as yum but they revamped it in dnf5 (it was initially supposed to be a whole new package manager with a different name)

[mhurron]

> Yeah I don't know why people are saying that speed doesn't matter. I use Homebrew and it is slow

Because how often are you running it where it's not anything but a opportunity to take a little breather in a day? And I do mean little, the speedups being touted here are seconds.

I have the same response to the obsession with boot times, how often are you booting your machine where it is actually impacting anything? How often are you installing packages?

Do you have the same time revulsion for going to the bathroom? Or getting a glass of water? or basically everything in life that isn't instantaneous?

[what]

This. There are much better reasons to abandon brew than “it’s slow”.

[pxc]

I would guess this change builds on the existing json endpoints for package metadata but that the Ruby DSL is remaining intact.

I think how to marry the Ruby formulas and a Rust frontend is something the Homebrew devs can figure out and I'm interested to see where it goes, but I don't really care whether Ruby "goes away" from Homebrew in the end or not. It's a lovely language, so if they can keep it for their DSL but improve client performance I think that's great.

[joemi]

Is Ruby really the speed bottleneck in Homebrew? I would assume it would be due to file operations (and download operations), not choice of programming language.

[SlightlyLeftPad]

Largely agree, though some things are notably difficult in some languages. Things like true concurrency for example didn’t come as naturally in Ruby because of the global interpreter lock. Of course there are third party libs, and workarounds though. Newer versions of Ruby bring it more natively, and as we’ve seen, Homebrew has adopted and makes use of that experimentally for a while, and the default relatively recently.

I can’t say that’s the only reason it’s slow of course. I’m on the “I don’t use it often enough for it to be a problem at all” side of the fence.