JuliaCon 2026

ReLint was developed at RelationalAI as an alternative to StaticLint. It already provides a set of \~50 built-in linting rules that can be run right after installing the package. At RelationalAI, it is used on a daily basis on a fairly large codebase (\~700K lines of Julia code).

One of the main goals of ReLint was to make it easier to write new rules. This was achieved with a design that allowed defining rules as types with associated check methods. For a simple rule, the definition might be as simple as the following:

struct AsyncRule <: ViolationLintRule end
function check(t::AsyncRule, x::EXPR)
    msg = "Use `@spawn` instead of `@async`."
    generic_check(t, x, "@async hole_variable", msg)
    generic_check(t, x, "Threads.@async hole_variable", msg)
end

However, complicated rules would require complex check functions that inspect the internals of Julia code. That is, of the EXPR representation of Julia code, which is not even the official representation. Hence, while this design is a major improvement upon StaticLint, it is still lacking expressivity, and it is not as tightly integrated with the Julia compiler as it could be.

Argus proposes a pattern matching framework that represents ASTs using JuliaSyntax, the official compiler front-end. It provides a DSL for expressing patterns that resemble the code they are meant to match. These patterns are used to define linting rules in an elegant manner:

VIOLATIONS = RuleGroup("violations")
@define_rule_in_group VIOLATIONS "@async" begin
    description = "Use `@spawn` instead of `@async`."

    pattern = @pattern ~or(
        @async({_}...),
        Threads.@async({_}...)
    )
end

There is no need for the user to write a custom check method – Argus's rule matching mechanism handles everything!

Argus's powerful pattern abstractions – syntax classes – offer a flexibility that ReLint's string-based patterns cannot match. The following rule, which warns against containers with abstract type parameters, would be impossible to express in ReLint:

@define_rule_in_group PERFORMANCE "containers-with-abstract-type-params" begin
    description = "Avoid containers with abstract type parameters."
    pattern = @pattern {container}{{_}..., {t:::abstract_type}, {_}...}
end

Argus seems to be the better choice for writing linting rules, but it is limited in terms of workflow integration. Here ReLint is a step ahead, embedding linting in GitHub actions and workflows. It allows automatic CI/CD checks for all rules and provides a pre-commit hook for catching severe violations especially early in the development cycle.

By integrating Argus, the latest ReLint release addresses the need for better static analysis tooling for Julia. The new linter still has the benefits of CI/CD integration and a pre-defined set of rules, but it greatly improves user experience and expressive power. Developers can now easily extend the default rule set by writing their own rules that look just like the code they want to match.

The package is openly available under the MIT license.

For more information you can watch the JuliaCon 2025 presentation on ReLint or the JuliaCon Paris 2025 presentation on Argus.