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.)
There are a lot of command line tools that are written in JS and other scripting languages.
Having the tools that are involved in interactive use be written in a compiled languages gives hope that they might be fast enough to not be annoying.
Me personally I do not install nodejs on my machines. So knowing that this tool is not written in JS is relevant for me.
As much as i'm a proponent of Rust, Go is very capable and is generally a great language. Its warts (as i see them) are not going to be apparent in the parallelism needed for a Git hook manager lol.
???
Also, this tool replaces another which was written in Go, which I would put in a similar performance category as Rust. It shouldn't make a difference in this scenario
In practice though, hooks sometimes run tools that are were not designed like that and instead modify the file (eg: formatters). However, this is usually done on staged files (in case of the pre-commit hook) and the modification is applied to the working copy. This can cause race condition in that one tool may overwrite the changes made by another tool. But since the source is not modified, it won't end up in a deadlock. It will also fail as desired. So the race is not serious. It will resolve itself after a few runs, unless something is done to prevent it in the first place.
I find hk's choice of programming language for hooks pretty exotic TBH.
This all made me look at lefthook, and it’s pretty darn interesting. I’d been missing out!
Could the Go solution add parallelism, sure. Did they? Not yet. Does that mean no other improvement in any other language can ever be written? No.
"Rust is faster" as an off the cuff comment that should have been left out seeing it has triggered some folks to hyper focus on that point.
They did: Lefthook lets you define a "group" where you can specify that every command should be done in parallel: https://lefthook.dev/configuration/group.html. In addition, it's possible to configure the whole hook to run in parallel through another property: https://lefthook.dev/configuration/parallel.html.
I'm assuming that Hk's innovation here is that it's a bit smarter with what it runs in parallel. Maybe it uses the globs to automatically run commands in parallel which targets different files?
> "Rust is faster" as an off the cuff comment that should have been left out seeing it has triggered some folks to hyper focus on that point.
It's not a a hyper focus: This was the first reason (out of only three) that Hk itself presented as a reason to use it over Lefthook. So yes, I agree: It should have been left out if the intention wasn't for people to focus on it. Put it somewhere in a footnote if it's not so relevant.
In general though, I agree that the blanket statement of “X is good because it’s language Y” is absurd, though I stubbornly cling to the opposite case for NodeJS, because I despise the idea of a frontend language running anything but a browser window. I have no objective defense.
It claims:
1) Rust is fast, so that helps some.
2) They run hooks in parallel, and that helps a lot.
I like knowing what language a tool is written in. If it's written in Python or JavaScript and it isn't something that's absolutely essential I can just immediately move on. It also lets me know if it's something I'd be willing to contribute to. It's odd that the authors mentioning the language is so triggering for you.
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.
> 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.
> 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.
Direct claim from the article.
First, I intend to be able to define simple "dependencies", but IMO that's not the interesting part.
I am going to use rw mutexes on every file with staged changes. If 2 steps are running against disjoint files there is no problem. If 2 steps are running against "check" (not "fix" which edit files by convention), they can also run at the same time. The only scenario where blocking is necessary is when you have 2 "fix" or 1 "check" and 1 "fix" on an intersection of their files.
For that scenario there is going to be a setting that you can enable to run a steps "check" command first (only if this scenario is about to happen, if no files will be in contention it will simply run "fix"), and if "check" fails, then it will switch to "fix".
This is my current idea and in my head I think it would work. There are caveats, notably running "check" and then "fix" might be slower than just waiting and running "fix" once which is why it needs to be optional behavior. You also may not care about things stomping on each other (maybe the linters themselves have their own locking logic).
I had submitted a PoC patch for the bash version that greatly sped it up, but there were a couple of tests I was struggling to get to pass, and I ran out of free time.
