Top
Best
New

Posted by Bogdanp 9/11/2025

Behind the scenes of Bun Install(bun.com)
431 points | 152 commentspage 3
djfobbz 9/11/2025|
I really like Bun too, but I had a hard time getting it to play nicely with WSL1 on Windows 10 (which I prefer over WSL2). For example:

  ~/: bun install
  error: An unknown error occurred (Unexpected)
lfx 9/11/2025|
Why you prefer WSL1 over WSL2?
tracker1 9/11/2025|||
FS calls across the OS boundary are significantly faster in WSL1, as the biggest example from the top of my head. I prefer WSL2 myself, but I avoid using the /mnt/c/ paths as much as possible, and never, ever run a database (like sqlite) across that boundary, you will regret it.
djfobbz 9/11/2025|||
WSL1's just faster, no weird networking issues, and I can edit the Linux files from both Windows and Linux without headaches.
rtpg 9/12/2025||
bun installs are fast, but I think they might be so fast and concurrent they cause npm to really get confused sometimes.

I end up hitting 500s from npm from time to time installing by bun and I just don't know why.

Really wish the norm was that companies hosted their own registries for their own usage, so I could justify the expense and effort instead of dealing with registries being half busted kinda randomly.

mnahkies 9/12/2025|
> Really wish the norm was that companies hosted their own registries for their own usage

Is this not the norm? I've never worked anywhere that didn't use/host their own registry - both for hosting private packages, but also as a caching proxy to the public registry (and therefore more control over availability, security policy)

https://verdaccio.org/ is my go to self hosted solution, but the cloud providers have managed solutions and there's also jFrog Artifactory.

One corollary of this is that many commercial usages of packages don't contribute much to download stats, as often they download each version at most once.

LeicaLatte 9/11/2025||
Liking the package management from first principles as a systems-level optimization problem rather than file scripting. resembling a database engine - dependency aware task scheduling, cache locality, sys call overhead - they are all there.
wojtek1942 9/11/2025||
> However, this mode switching is expensive! Just this switch alone costs 1000-1500 CPU cycles in pure overhead, before any actual work happens.

...

> On a 3GHz processor, 1000-1500 cycles is about 500 nanoseconds. This might sound negligibly fast, but modern SSDs can handle over 1 million operations per second. If each operation requires a system call, you're burning 1.5 billion cycles per second just on mode switching.

> Package installation makes thousands of these system calls. Installing React and its dependencies might trigger 50,000+ system calls: that's seconds of CPU time lost to mode switching alone! Not even reading files or installing packages, just switching between user and kernel mode.

Am I missing something or is this incorrect. They claim 500ns per syscall with 50k syscalls. 500ns * 50000 = 25 milliseconds. So that is very far from "seconds of CPU time lost to mode switching alone!" right?

Bolwin 9/11/2025|
Read further. In one of the later benchmarks, yarn makes 4 million syscalls.

Still only about 2 secs, but still.

yahoozoo 9/12/2025||
Good article but it sounds a lot like AI wrote it.
phildougherty 9/11/2025||
Bun is FUN to say.
swyx 9/11/2025||
i'm curious why Yarn is that much slower than npm? whats the opposite of this article?
WesolyKubeczek 9/11/2025||
macOS has hardlinks too. Why not use them?
moffkalast 9/11/2025||
Anyone else also having a first association to https://xkcd.com/1682 instead of, you know, bread?
jcmartinezdev 9/11/2025|
[dead]
More comments...