We've been using semgrep for Zulip's python codebase for the last few months; here's our configuration: https://github.com/zulip/zulip/blob/master/tools/semgre

We've been using semgrep for Zulip's python codebase for the last few months; here's our configuration: https://github.com/zulip/zulip/blob/master/tools/semgrep.yml https://github.com/zulip/zulip/blob/master/tools/semgrep.yml I really appreciate the semantic checks. They're especially nice for security-sensitive lint rules, but really it removes the hacky regular expressions feel of adding lint rules to a codebase. It's also been useful for some codebase migrations (semgrep is more precise than e.g. `git grep -w` for finding "All the places we use code pattern X that we want to stop doing"). My main complaint about it is performance -- it's too slow per unit rule for us to replace the regular expression based system that we run on our whole codebase (so we can't happily convert our other ~100 regular expression-based lint rules to semgrep (https://github.com/zulip/zulip/blob/master/tools/linter_lib/custom_check.py https://github.com/zulip/zulip/blob/master/tools/linter_lib/...). But performance has been improving a lot over time, and I think there's potential for it to be faster (E.g. mypy, the Python type-checker, has gotten way way faster in the last year or two). Because semgrep is getting active investment from a venture-funded company that I imagine will improve the performance, I expect semgrep to be a tool that most projects serious about code quality are using in a few years. I should add that performance may also be less important to others than it is to us; we run all of our linters (currently 20 distinct linters, including eslint, prettier, pyflakes, isort, shellcheck, etc.) in parallel using https://github.com/zulip/zulint https://github.com/zulip/zulint, with the goal of being able to lint the entire codebase in <30s or changed files in under 1s (obviously time depends on number of files changed).