zlacker

>>DrBenC+(OP)
> lefthook is written in go, hk is written in rust. This will make hk faster but the advanced parallelism logic in hk should make hk much faster. Because git hook managers are often limited not by their own logic but the speed of the commands they run, this should make hk significantly faster in real-world usage.

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

>>judofy+2b
This project is brand new. I've only spent 3 days on it and this doc I half finished today. That said, I just did some benchmarks and it certainly is much faster than its peers. 4.6x faster than lefthook and 6.1x faster than pre-commit (in the best case).

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.

>>jdxcod+QI
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.