Maintenance Status

[NoahTheDuke]

I have taken over maintenance of Kibit and pulled it into the clj-commons umbrella. I am still getting familiar with the codebase but would like to release some small updates to handle "bugs" like reader conditionals and ##Inf.

However, I am not sure that there needs to be a future for Kibit otherwise. It has served its purpose fairly well but the use-cases for it continue to shrink as other linters have grown in maturity. Namely, clj-kondo and eastwood are both quite good for their use-bases when they overlap with Kibit.

For purely shape-based linting, there's a project I began working on before being given control of Kibit, called Splint. It runs significantly faster than Kibit, has more support for all of Kibit's existing rules and can support writing custom rules, and has nearly the same set of features as Kibit.

I think the best option here is to focus on making Kibit stable and then deprecating it.

What do y'all think?

[port19x]

I can't disagree with the sentiment that kibit overlaps at all with clj-kondo or eastwood.
I use all 3 + cljfmt through lsp.

Kibit, for me, is a linter that points me to cool clojure functions I didn't know about.
Clj-kondo and eastwood make sure I don't shoot myself in the foot or write grossly unidiomatic clojure.
kibit tells me to use (fnext x) instead of (first (next x))
kibit tells me to use (not= a b) instead of (not (= a b))
If these kind of things are also done by splint and that's what you mean with "shape", then there might be some overlap.
Otherwise please take good care of this linter and/or invite me to comaintain it with you.

tldr: kibit is more useful and more important to me than clj-kondo and eastwood combined.

[port19x]

Citing the splint readme:

It aims to warn about many of the guidelines in the Clojure Style Guide.

No. Literally the first line of the kibit readme tells you what it tries to achieve:

There's a function for that!

It's an idiom checker that reduces the nesting of your parenthesis by suggesting idomatic alternatives to common compositions as noted in my previous comment.

cljfmt is the project that cares about clojure style and formatting.

[NoahTheDuke]

I take your point about the Splint readme. "There's a function for that!" is much more clear than what I wrote. Instead of defending referencing the "Clojure Style Guide", I'll say that Splint covers all of the same "There's a function for that" idiomatic substitutions Kibit does (except it suggests using clojure.math instead of raw interop) and does not/cannot make any formatting suggestions because it relies on edamame (a feature-rich alternative to tools.reader). It is currently all of Kibit's "here's a better function" substitutions plus a number of other related substitution rules.

tldr: kibit is more useful and more important to me than clj-kondo and eastwood combined.

That's good to know. I'll hold off on deprecating it then.

[port19x]

I believe you that splint is likely superior in implementation to kibit, tho kibit is way more discoverable.
I spent half a week some time ago researching and trying out different clojure linters and didn't stumble across splint.
Maybe you can PR it into awesome-clojure and a few other lists, make a reddit post about it or otherwise make it more discoverable

[NoahTheDuke]

I've updated the maintenance status in the readme: 5b40c3a

kibit is currently in maintenance. It will receive bug fixes and support for new versions of Clojure, but there are no plans for major changes or additions to the core functionality. Why not? core.logic is very clever but quite slow, and the existing architecture is such that to move away from core.logic would be to rewrite almost the entire library.

To expand on it, I spent roughly 10 hours over the last week reading and evaluating the kibit code base, looking for ways to improve the overall speed and robustness. However, the fundamental requirement of core.logic is too great. It's an incredible library that does exactly what it needs to, but it's too slow to be used at any scale. Even on simple cases such as '(do (when test then)), it takes 10-20x longer to evaluate with the current set of ~70 (fairly simple) rules than Splint does with ~110 rules.

Any changes to the code-walking logic (using hand-written code walking instead of tree-seq, only constructing a simplify-map after checking the guard, removing laziness, etc) barely change the performance because of how much time is spent in the core.logic code running the rules. I also experimented with embedding splint directly in kibit, treating kibit as a wrapper around splint, but that required enough effort that I think it's better for interested users to just switch to splint.

I think keeping kibit up to date with changes to Clojure (syntax changes, etc) is valuable. Those who want to continue using it shouldn't be held back by updating their codebase to Clojure 1.12+. However, I recommend that everyone consider using other tools (splint, clj-kondo, eastwood, etc).