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
Why mention Rust at all? How is that possibly relevant to the problem? There seems to be a lot of projects that are rewrites of existing project in Rust where the fact that they are in Rust seems to be their distinguishing feature. Languages are less important than the solutions that a piece of software provides.

>>doug_d+Oe
> Why mention Rust at all? How is that possibly relevant to the problem?

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.

>>codetr+sg
> There are a lot of command line tools that are written in JS and other scripting languages.

???

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