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
Overall, the whole logic "A is written in X, but B is written in Y, hence it is faster" is so deeply flawed, that one has to consider a possibility that the author doesn't understand the mere basics of computer program engineering. There are so much nuances that I don't even want to start untangling it.

>>Arech+yi
mise (née rtx), by the same author, could confidently claim this because the tool it replaced – asdf – is written in bash. Bash is perfectly capable for a great many things, but unless you’re getting fairly deep into the weeds of what it can do (e.g. eschewing external calls to sed et al. whenever possible in favor of parameter substitution), you’ll tank performance from sub-shell spawn times. mise was objectively and obviously faster out of the box, though nearly any language that included basic text processing functionality would’ve been acceptably fast.

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.

>>sgarla+Er
`asdf` has now been rewritten in Go for anyone interested, so choosing mise over it due to performance is less of a concern now.

>>dlisbo+Sv
Oh, good to know! Kinda sad that they gave up on bash; I wonder how they’ll differentiate themselves now.

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.