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:
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.
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