zlacker

I'm sorry, but it's very hard to take this project seriously: You originally claimed that it was 1.5x faster than Lefthook, but then you removed the parallel support from the Lefthook (https://github.com/jdx/hk/commit/ad473331db2866f6574555ac4b0...) and changed your claim to "4.6x faster". These numbers are also just for some a specific workload (Prettier, ActionLint, pkl eval, ripgrep, cargo fmt) on this specific repo. For now the "4.6x number" is heavily based on the fact you have five jobs and Hk runs commands in parallel by default while you let Lefthook run them sequentially. I bet you can turn that number into 10x if you just add a few more jobs!

> Despite what everyone here says: yeah, just doing CLIs in Rust will be faster than Go and for CLIs like this milliseconds matter.

You've shown nothing to suggest that this is true. On my computer "lefthook --help" is exactly as fast as "hk --help". There's also many other differences between these tools. YAML vs Pkl is one difference. Another one is that Lefthook shells out to "git" to determine the list of staged files, while Hk uses libgit2. Which of these are faster? I'm not sure! It might even depend on repository size and/or other details. And as we all agree: In practice the parallelism strategy will matter the most.

> As I said in the doc I think real-world performance in a large codebase will show that hk is even faster still

I'm absolutely sure that you will be able to tweak hk to become the "fastest" pre-commit runner in your designated category. I'm also pretty sure that similar optimizations will apply quite easily to Lefthook. They're after all doing pretty much the same thing.

>>judofy+(OP)
of course I selected the best benchmark. Once I ran a benchmark that had higher numbers I edited my response—I was up front about that. So far 0 benchmarks show that lefthook is faster and I doubt there could be one knowing how both of them work. I'm not just creating scenarios where I know hk will outperform but I'll certainly highlight the best one.

> then you removed the parallel support

that was not intentional. I fixed that, but it didn't change the results that much:

https://github.com/jdx/hk/commit/dfe1fc1724b8f6c43b184dc98ac...

In any case, I don't know why anyone would take such a new project "seriously". I certainly don't.