Yep, forgot to mention that in my post, thanks.

Also, it was originally written in both Go and Rust, and the author decided to continue in Go. Both are fine languages, but it makes an interesting case study:

https://news.ycombinator.com/item?id=22336284

Wow, thank you for sharing this. The author echoes a lot of thoughts I've had working with rust.

However, doesn't the explanation given for why the Go version was 10% faster mean that esbuild was built to take advantage of a fixed number of cores rather than all of them? Sorry if this is a dumb question, I'm not really that experienced with parallel computation

I'm not sure. From the description, it sounds like whatever rust does on one thread (compute + destructors) is split across multiple threads in Go (compute + gc), but it's not clear if the base computation workload is spread across multiple threads.

Thinking about the problem, I think that at the very least parsing could be parallelized. Assembling everything into one output might not be parallelizable. But I haven't looked at what happens in esbuild.

I do know that it's fast enough that when I switched from webpack I had to check that it actually did something, because it returned immediately.