Remix.run Logo
SOLAR_FIELDS 7 hours ago

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

petcat 5 hours ago | parent | next [-]

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 4 hours ago | parent | next [-]

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 3 hours ago | parent [-]

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.

novok 4 hours ago | parent | prev | next [-]

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

akdev1l 3 hours ago | parent | prev | next [-]

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 2 hours ago | parent [-]

> 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 2 hours ago | parent [-]

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 3 hours ago | parent | prev [-]

> 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?

pxc 3 hours ago | parent | prev [-]

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.