zlacker

It makes sense. If you have 4 hooks, and you run them serially, it will be slower than if you ran them in parallel.

>>searea+(OP)
I say this as a huge fan of Rust, Rust adds almost nothing to this kind of parallelism.

>>searea+(OP)
That assumes the hooks themselves can be run in parallel. Without a way to describe dependencies between them there's big scope for race conditions.

>>searea+(OP)
Sure, but Go can do things in parallel too. How is Rust's faster than Go's, especially if they're limited by the speed of the commands they run?

>>great_+36
Imo this problem would be fine in either Go or Rust. I've done both. For extreme cases you can, i imagine, make Rust parallelism faster than Gos, but by default if you just design them similarly -- eg: throwing Tokio at the problem and not hyper optimizing Rust -- i imagine they'd perform quite similarly.

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.

>>rounce+T5
Hooks are generally not meant to modify the source code. They should ideally just analyze the code and either succeed (exit code 0) or fail. Race conditions won't happen in such situations.

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.

>>vlovic+M5
It doesn't claim that.

It claims:

1) Rust is fast, so that helps some.

2) They run hooks in parallel, and that helps a lot.

>>rounce+T5
Which is why it is best if you plan for parallelism from the beginning, so that your configuration has a straightforward way to indicate dependencies and making sure certain hooks aren't run in parallel with conflicting hooks

>>thayne+bw
The subject program doesn't seem to provide a way in which to specify the dependencies between hooks, hence they will just race each other assuming they are all fired off in parallel.

>>great_+36
It mentions "lefthook" by name. I'm guessing that specific go-based hook manager doesn't do this parallelism. So it's saying "rust instead of go might give a small performance boost, but that's not where most of the performance boost comes from".

>>searea+Vu
I was replying to OP not the article. The article really muddles through and hand waves away the Rust vs Go - I’m seriously skeptical the overhead of the language would show up at all with the work being done here.

>>vlovic+p51
You are moving the goalposts? You first claimed that Rust doesn't help with parallelism. I pointed out they never claimed it did. Now you are talking about something else?

>>searea+ki1
> lefthook is written in go, hk is written in rust. This will make hk faster

Direct claim from the article.

>>rounce+zH
in fact I do believe I have a solution to this problem. I should have this fully implemented soon but right now it is not.

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