This project was fun and interesting, but I haven't put a significant amount of work into it for over a year.
The project aimed to solve two main use cases, which I'll cover below. It's also worth noting that a significant part of the initial design came from @rogpeppe.
Querying Go code
One good example is writing custom linting checks. One can always use go/ast and go/types, but having to do that for every little query or check is overkill.
We have https://pkg.go.dev/golang.org/x/tools/go/analysis today, so the barrier to entry has been significantly lowered.
There have also been other projects started in this space since, such as https://semgrep.dev/ (which supports many languages) and https://github.com/quasilyte/go-ruleguard (which actually forked our pattern-matching syntax and code, I think).
Refactoring Go code
This was done by
gofmt -r or
eg, but they were both too simple to accomplish anything non-trivial.
I firmly believe that refactoring Go code is better served by https://github.com/rsc/rf in the future. That tool is still alpha, but its design is clearly better in multiple ways. It's already been used to refactor Go's own compiler in many ways that gogrep simply does not support, for example.
Current design problems
The API is a list of commands, which is too limiting if one wants to write complex queries. See https://github.com/mvdan/gogrep/issues/32. I tried to do a refactor for this in early 2020 (https://github.com/mvdan/gogrep/commit/e933f34b68d0b10e7f5b1fb1fa14491b688ab9ff), but I didn't particularly like the result either.
The pattern matching is sometimes too stiff; see https://github.com/mvdan/gogrep/issues/4 and https://github.com/mvdan/gogrep/issues/52.
The matching could be more clever, such as comparing evaluated constant values: https://github.com/mvdan/gogrep/issues/43
I don't plan to invest the significant amount of time it would take to make gogrep a competitive tool again, given that it's been outpaced in both use cases as outlined above. Frankly, I'm pretty okay with
rf as Go-specific ways to solve both problems in a satisfactory way, and they are both well maintained and better designed.
So I think that gogrep, as a tool in its current form, should be deprecated. There's little reason to recommend its use to others. It would also help reflect the current state of the project.
I still think that there might be value in continuing to develop the internal matching syntax and logic. See https://github.com/mvdan/gogrep/issues/55, for example. I would have absolutely no problem with that, but I don't plan to do that myself.
If someone is willing to step up and take ownership of this project, including the end-user tool, I'm happy to give that person write access - and eventually transfer the repository, once it's shown a bit of progress.
Assuming noone steps up, I think the best course of action is to deprecate the tool and freeze this GitHub repository. Current users of the tool could continue to use it, though the deprecation should discourage them. This would also impact ruleguard, but I think they could simply continue to maintain the pattern matching code in their own repository.
Either way the project goes, it's going to be a relief for me - I have other cool stuff that I want to work on, and it's unfair for me to keep this project in its current state if I don't plan to continue it :)
I'll leave this issue open for two weeks before making a decision.
CC @rogpeppe @quasilyte, given your past contributions.