What a strange sentence. First Hk will be faster than Lefthook because it will be written in Rust[1], but then later on it says that it doesn't actually matter? But either way it will be faster because it has "advanced parallelism"?
Looking at the comparison to Lefthook it's not clear to me why this isn't a PR to Lefthook. It's already a well-established solution which is present in many package managers. Surely the distinction between "checks" and "fixes" would be possible to introduce there as well?
Do we yet another tool instead of working together on improving the existing ones?
[1]: Which also is not a given. Programs which allocate a lot can be faster in Go since the garbage collector only works on the live set of objects whereas Rust have to explicitly deallocate all memory. CLI tooling is actually kinda a sweet-spot of GCs: You don't want to spend time reclaiming memory until you reach a certain threshold of used memory. In scenarios where you use less than the threshold you end up spending zero cycles on deallocation. (And completely leaking all memory is bound to cause problem on bigger commands or smaller machines.)
I'll put these benchmarks on that page in different scenarios.
Update: https://github.com/jdx/hk/blob/main/docs/public/benchmark.pn...
As I said in the doc I think real-world performance in a large codebase will show that hk is even faster still—though that will depend on the project in question. It's really just a matter of providing the right levers in the right places and having good defaults.
Despite what everyone here says: yeah, just doing CLIs in Rust will be faster than Go and for CLIs like this milliseconds matter.
