u/Admirable-Anybody937

I'm building a linter that shows you the idiomatic rewrite of your code — not just the error. Starting with Go, planning support for more languages. Looking for honest feedback before I go further.

Here's the problem:

I care about being a generalist engineer — someone who picks the right tool for the problem rather than forcing every problem into a familiar stack. But every time I pick up a new language seriously, I hit the same wall: syntax in days, idioms in months. And there's no shortcut.

Every language has idioms that are load-bearing. Violate them and your code is technically correct but written against the grain — and anyone who actually knows the language will see it immediately in code review:

• Clojure/Elixir: immutability, side-effect discipline, data-in/data-out. FP isn't a pattern here — it's the contract.
• Go: explicit errors, flat structure, concurrency as a first-class concern. Clean over clever, always.
• Rust: ownership and borrowing aren't restrictions — they're the design. Fight them and you'll lose.
• Python: "Pythonic" is real — readability, duck typing, idiomatic stdlib usage.

I've seen this constantly — senior engineers included:

— Go service built with OOP-style LLD. Interfaces on everything, Java-style abstraction hierarchies. Compiles fine. Fights you in every code review. — Python production codebase with type hints ignored throughout. "It runs" — until refactoring becomes archaeology. — Clojure code reaching for atoms constantly because mutability feels comfortable. That escape hatch wasn't meant to be the default.

These don't fail tests. They don't get caught by existing linters. But they're the exact patterns that slow teams down, create review debt, and make onboarding painful.

The tools we have today don't help here. golangci-lint, clippy, pylint — excellent at catching bugs and style violations. None of them tell you how a senior engineer in this language would have written it differently, and why.

So I'm building idiom.

Starting with Go because it's where I'm strongest, but the architecture is language-agnostic from day one. Each language gets its own rule set grounded in its official style guides, community standards, and the reasoning behind how the language wants to be written.

The difference in output, using Go as the example:

# Every linter today:
func.go:12: naked return in function longer than 5 lines

# idiom:
func.go:12  [anti-pattern: naked-return]

  Your code:
    func split(sum int) (x, y int) {
        x = sum * 4 / 9
        y = sum - x
        return
    }

  Idiomatic:
    func split(sum int) (int, int) {
        x := sum * 4 / 9
        return x, sum - x
    }

  Why: Naked returns make code harder to read in non-trivial functions.
  Effective Go explicitly discourages them outside of very short functions.

The same pattern applies to every language — your code, the idiomatic version, and the reasoning behind it. Not a generic style guide. Language-specific, idiom-aware.

Technically for Go v1: built on go/analysis (type-aware, not regex), ships as a golangci-lint plugin + standalone CLI, outputs SARIF for GitHub PR annotations. Each language will use its native AST/analysis tooling.

Go v1 rules planned: naked returns, missing error wrapping, bool params that should be functional options, interface defined next to its only implementation, Java-style constructors, context not as first param, string concatenation in loops, goroutines without lifecycle management.

Before I go further, genuinely want to know:

• Have you felt this gap between "it compiles" and "it's actually idiomatic" — in Go or any other language?
• What anti-patterns do you see constantly in real codebases that existing linters don't catch?
• Which language after Go would you most want to see supported?

Not looking for hype — looking for honest signal on whether this fills a real gap or if I'm solving something already solved well enough.

I'm building a linter that shows you the idiomatic rewrite of your code — not just the error. Starting with Go, planning support for more languages. Looking for honest feedback before I go further.

Here's the problem:

I care about being a generalist engineer — someone who picks the right tool for the problem rather than forcing every problem into a familiar stack. But every time I pick up a new language seriously, I hit the same wall: syntax in days, idioms in months. And there's no shortcut.

Every language has idioms that are load-bearing. Violate them and your code is technically correct but written against the grain — and anyone who actually knows the language will see it immediately in code review:

• Clojure/Elixir: immutability, side-effect discipline, data-in/data-out. FP isn't a pattern here — it's the contract.
• Go: explicit errors, flat structure, concurrency as a first-class concern. Clean over clever, always.
• Rust: ownership and borrowing aren't restrictions — they're the design. Fight them and you'll lose.
• Python: "Pythonic" is real — readability, duck typing, idiomatic stdlib usage.

I've seen this constantly — senior engineers included:

— Go service built with OOP-style LLD. Interfaces on everything, Java-style abstraction hierarchies. Compiles fine. Fights you in every code review. — Python production codebase with type hints ignored throughout. "It runs" — until refactoring becomes archaeology. — Clojure code reaching for atoms constantly because mutability feels comfortable. That escape hatch wasn't meant to be the default.

These don't fail tests. They don't get caught by existing linters. But they're the exact patterns that slow teams down, create review debt, and make onboarding painful.

The tools we have today don't help here. golangci-lint, clippy, pylint — excellent at catching bugs and style violations. None of them tell you how a senior engineer in this language would have written it differently, and why.

So I'm building idiom.

Starting with Go because it's where I'm strongest, but the architecture is language-agnostic from day one. Each language gets its own rule set grounded in its official style guides, community standards, and the reasoning behind how the language wants to be written.

The difference in output, using Go as the example:

# Every linter today:
func.go:12: naked return in function longer than 5 lines

# idiom:
func.go:12  [anti-pattern: naked-return]

  Your code:
    func split(sum int) (x, y int) {
        x = sum * 4 / 9
        y = sum - x
        return
    }

  Idiomatic:
    func split(sum int) (int, int) {
        x := sum * 4 / 9
        return x, sum - x
    }

  Why: Naked returns make code harder to read in non-trivial functions.
  Effective Go explicitly discourages them outside of very short functions.

The same pattern applies to every language — your code, the idiomatic version, and the reasoning behind it. Not a generic style guide. Language-specific, idiom-aware.

Technically for Go v1: built on go/analysis (type-aware, not regex), ships as a golangci-lint plugin + standalone CLI, outputs SARIF for GitHub PR annotations. Each language will use its native AST/analysis tooling.

Go v1 rules planned: naked returns, missing error wrapping, bool params that should be functional options, interface defined next to its only implementation, Java-style constructors, context not as first param, string concatenation in loops, goroutines without lifecycle management.

Before I go further, genuinely want to know:

• Have you felt this gap between "it compiles" and "it's actually idiomatic" — in Go or any other language?
• What anti-patterns do you see constantly in real codebases that existing linters don't catch?
• Which language after Go would you most want to see supported?

Not looking for hype — looking for honest signal on whether this fills a real gap or if I'm solving something already solved well enough.