At the time it was written, this feature was only really useful for Facebook (which has some linters which take quite a long time to run). I don't recall hearing complaints about slow linting from other installs since then. Are you hitting issues with linter performance?

The big issues with this feature were:

• There was no message calling out the cache usage. I think we added one around the time we disabled the cache by default.
• Users routinely ran into confusion while developing and testing linters and lint bindings, which are very difficult to version (e.g., you'd change some PHP code and re-run the linter, and it would silently pick up the cache).
• At the time, many of the linters in question were written in PHP. This is less true now, and exposing versions tends to help the cache invalidation situation.
• (For most installs, the expected performance benefit is probably small?)

I don't currently intend to ever turn this on by default again, but seeing more reports of linter performance issues could change my mind. Some thoughts:

• Enabling this per linter in .arclint might make sense.
• Enabling this only for arc diff -- not arc lint -- might reduce the rate of false positives, which mostly occurred during linter development and debugging.
• IIRC, it was disabled by default shortly after (or at the same time as?) messages were added, so the messages might have reduced the rate of false positives substantially on their own if given time. I generally agree that we're in a better position here than we were at the time the cache was disabled by default.

My particular pain point at the moment is running arc lint --everything, which probably isn't a common use case. The last time that I ran this over our code base (which is quite large) it took around 20-30 minutes. We have more linters setup now so it likely takes a lot longer.

@epriestley, what are your thoughts on this? I'm happy to just close this maniphest if you do not intend to enable lint.cache by default.