[sondr3]

I can't speak for the authors of Rolldown, but esbuild is essentially a one-man show and everything is bespoke and written for esbuild. Not saying this as a bad thing, Evan single-handedly improved bundling performance for Node and started us down this path of tools in Rust. The libraries and ecosystem for writing tooling for other languages is really taking off with projects like oxc, SWC, LightningCSS, Biome, rslint, Deno, rspack, napi-rs/Neon for JS/TS/Node etc plus ruff, uv, rattler, pixi for Python and so on, so you get a proliferation of libraries and authors that can share and help each other.

Plus, on a personal level, using a language with pattern matching and algebraic data types makes writing tooling for parsers and such much more ergonomic than in languages without.

[lelandfe]

> esbuild is essentially a one-man show and everything is bespoke and written for esbuild. Not saying this as a bad thing

Not being glib: you didn’t mention why you brought that up.

[ericyd]

My understanding (could be totally wrong) is that esbuild has historically been less open to widespread collaboration than some other open source projects, so adding the features they needed may have been untenable.

I have no authority and will not stand behind these claims if challenged.

[gsuuon]

> I have no authority and will not stand behind these claims if challenged.

I want this on a shirt

[oogali]

A friend once explained this concept to me as “strong opinions, weakly held”.

[cAtte_]

note that esbuild is written in go, not rust

[dunham]

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

[pcthrowaway]

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

[dunham]

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.

[sondr3]

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