Live data from Hacker News

Sapphire: Rust based package manager for macOS

github.com

91–100 of 311 posts

Re: Sapphire: Rust based package manager for macOS

#92

It’s a real disservice to the project not to give a raison d’etre in the readme, or any kind of technical motivation / differences.

> It’s a real disservice to the project not to give a raison d’etre in the readme, or any kind of technical motivation / differences. This. There's a wave of projects whose only value proposition is this vacuous "let's reinvent the wheel in Rust" sales pitch, where nothing of value is proposed beyond throwing around the Rust buzzword.

Is it really necessary to restate the advantages of rewriting in Rust in every such project? Compared to Ruby programs Rust programs are faster, more robust, more maintainable, and easier to install. That's pretty much the same for any Rust rewrite (e.g. uv).

It would be interesting to know if there are other goals though, e.g. UX improvements.

Re: Sapphire: Rust based package manager for macOS

#93

With my Homebrew hat on, but not speaking for others: I think this is pretty cool, and demonstrates something that we've discussed indirectly for years. At its core, there are really two parts to Homebrew: 1. There's the client side, i.e. `brew`, which 99.9% of users stick to happy paths (bottle installs, supported platforms) within. These users could be supported with relative ease by a small native-code installer,…

> but parallel downloads of things like bottles and DMGs is not an architectural limitation of Homebrew itself, but instead a conscious decision to trade some install speed for courtesy towards the services we fetch from That doesn't make sense. As you say you're directing a huge volume of traffic so it makes no difference exactly when a user downloads a byte. It all gets smeared out. Only the total amount of data ma…

> As you say you're directing a huge volume of traffic so it makes no difference exactly when a user downloads a byte. It all gets smeared out.

Homebrew's traffic pattern is not a uniform distribution. Package updates go out, and users download those packages in structured ways: there are spikes for MDM-managed Homebrew installations, spikes for cronjobs and CI/CD systems, spikes at 9AM on different coasts when developers sign into their machines, etc.

(How much this matters is also not uniform: it matters somewhat less for GitHub Packages - they should have a hefty CDN - and it matters somewhat more for Casks, which tend to be large DMGs hosted on individual servers.)

Re: Sapphire: Rust based package manager for macOS

#94
post #76

Homebrew sure has room for improvement, as most software does, and I appreciate every effort to replace and renew what we have with something better. But my own grievances with Homebrew isn't with the codebase itself. What discourages me from using Homebrew is the intent and the mindset of its developers and packagers, who, I think, see their goal building an "unstable" distribution, as Debian defines it: "[a distrib…

I mainly disagree with the Homebrew stance on sudo/root. They claim it's better to install everything under a user dir, but 10% of the time that doesn't work for whatever reason, and tons of users have screwed up their permissions trying to fix it. No other package manager has this issue.

Re: Sapphire: Rust based package manager for macOS

#95
post #67

It’s a real disservice to the project not to give a raison d’etre in the readme, or any kind of technical motivation / differences.

1. I thought "Sapphire is a next‑generation, Rust‑powered package manager inspired by Homebrew" covered it pretty well. 2. It's a personal project. 3. It's explicitly declared as alpha software.

Yeah, the HN title was editorialized as a Homebrew "replacement," which may be ticking people off.

Re: Sapphire: Rust based package manager for macOS

#96
post #81

Cool, but why not use https://mise.jdx.dev/ ?

That's a totally different tool. Brew is a generic package manager that installs ... basically everything. Mise is specifically for managing compilers and associated tooling. You can't install libgmp or mplayer with Mise.

Re: Sapphire: Rust based package manager for macOS

#97
post #53

Earlier quoted context omitted.

Homebrew is 99% IO-bound and this will be too. Installing (prebuilt) packages doesn't require much logic. If this tool supports parallel downloads, it will be 10x faster than Homebrew, but it won't have anything to do with the language. The issue is finding a hosting provider willing to be DDOS'd for the good of the open-source community.

> If this tool supports parallel downloads, it will be 10x faster than Homebrew, but it won't have anything to do with the language. If this is true, why are the Rust tools, on average, so much faster than the JS (or whatever) tools they replace? Hint: the answer hasn't just to do with the theoretical technical merits of the underlying platform, but also what type of developer they attract.

Do you have an example of a faster Rust tool that replaced an IO-bound JS tool? The toolchain ones that got Rust replacements were CPU-bound afaik.

Re: Sapphire: Rust based package manager for macOS

#98

Earlier quoted context omitted.

P2P protocols like BitTorrent are made for this kind of problem.

Sure. There's also a reason no major OSS packaging ecosystem uses these protocols: the only thing worse than a slow distribution scheme is an unreliable one. Combine that with the (reasonable) lack of a reward scheme for seeding an OSS packaging ecosystem, and you have a distribution mechanism that's significantly more brittle than the current "throw a lot of bandwidth at it" approach. (Among other technical challeng…

I think you are misinformed as BitTorrent, for instance, is much more reliable than https alone. The reward scheme is built in already: the client uploads while it's downloading and installing and prioritizes the clients it is downloading from. At worst, the reliability and performance are the same as the web seed.

Generating additional metadata at bottle build time doesn't appear to be much of a technical challenge either.

Re: Sapphire: Rust based package manager for macOS

#100
post #44

This looks like a fun little project, nice work! I'm not a big fan of keeping the Homebrew terminology though. I never know what a formula, keg, cask, cellar, tap or bottle is. Why not keep to the standard terms of package and repository etc? I don't know beer brewing terminology or how beer brewing is analogous to package management, and I honestly wish that it wasn't something which my tools expect me to learn.

As an experienced homebrewer, I don't think knowing about making beer makes it any clearer to me. Why do I need to install Docker from a Cask? Oh, it's because on Mac, a Cask is actually a Mac package (DMG or PKG or something). It's just arbitrary beer-flavored terminology.

No different than the Windows registry, which apparently uses a honeybee / hive metaphor because some Windows dev hated bees and their teammates liked trolling them.

Post reply on HN