[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”.