Show HN: I ported Tree-sitter to Go

Original Article ↗ Hacker News Discussion ↗

CGO-free Tree-sitter in Go & practical use cases

  • Major interest from Go ecosystems that currently rely on CGo Tree-sitter: Bazel/Gazelle, gopackagesdriver, Go-based forges, and tools with strict no-CGo requirements.
  • Go forges (e.g. Gitea/Forgejo) are highlighted as beneficiaries for fast syntax highlighting; one report claims ~20x speedup vs a previous regexp-based highlighter.
  • Zig and other language tool authors are attracted by lower binary sizes and easier distribution.

Structural VCS built on gotreesitter (“got”)

  • Author explains “got” as a structural VCS optimized for concurrent edits to the same file.
  • Features mentioned:
    • Entity-aware diffs (e.g. function-by-function instead of line-based).
    • Structural blame and per-entity history insensitive to file renames/moves.
    • Semver suggestions inferred from structural changes.
    • Structural merges with 3-way text merge as fallback when parsing fails.
  • It interoperates with Git repositories: local structural features, remote Git forges.

Naming, layout, and ecosystem fit

  • Concerns about confusion with existing “Got” VCS and a popular JS HTTP library “got”; others dismiss this as irrelevant because those are niche for many users.
  • Multiple joke name suggestions; no consensus.
  • Some dislike the non-standard repository/package layout for a Go project, though others say tests-with-implementation is “just Go style.”

Grammars, binary size & performance claims

  • All bundled grammars (~206) together reportedly add ~15 MB, considered very acceptable for CLIs shipping many languages.
  • Grammars are said to track the official Tree-sitter ones; ~70% of effort went into porting external scanners; currently one scanner (norg) is missing.
  • A “partial” parsing mode without all scanners is called out as producing guaranteed-incorrect outputs for some grammars; using this for a “90x faster” benchmark is criticized as misleading.
  • Critics note the benchmark mostly measures CGo call overhead vs pure Go; no algorithmic speedup is demonstrated.

Completeness, maintenance & WASM

  • Some users find it incomplete for advanced use cases (e.g. lack of TreeCursors and on-the-fly grammar generation), making it unusable for them.
  • Questions raised about long-term maintenance, staying in sync with upstream Tree-sitter, and whether a WASM-based approach (official TS WASM + Go WASM runtime) would be safer for the future.

AI/LLM-generated code controversy

  • Multiple commenters assert the README and code look like LLM-generated “vibe code,” and criticize the lack of explicit disclosure.
  • Concerns:
    • Higher perceived risk of subtle bugs and “nonsense” behavior in AI-written code.
    • Misleading to present the project as a “rewrite/port” without stating AI involvement or how much of the test suite passes.
    • Some would only use it after personally reviewing the code; others dismiss it outright for production.
  • Counterarguments:
    • Tools (LLMs, editors, methodologies) are just part of the workflow; what matters is tests, static analysis, and code review.
    • Demanding “AI provenance” in READMEs is seen by some as dogmatic and not scalable, especially with agentic tools.
    • If code passes strong test suites and fuzzing, its origin is argued to be less important.
  • Broader debate touches on:
    • Whether AI-written OSS should always be labeled.
    • The erosion of “depth and integrity” vs the practical goal of “useful programs.”
    • Analogies to overfitting, libraries, and long-term technical debt.

Security tangent and accusations

  • A commenter working on a CRDT-based VCS describes a server break-in and implies suspicious timing with this Go Tree-sitter port; no concrete evidence is provided.
  • Others strongly question this implication and urge caution, suggesting the situation may be more personal than technical.
  • “Evil maid” attacks are briefly explained as a security concept (untrusted physical access by cleaners, etc.).

Relationship to LSP

  • Clarification: Tree-sitter provides incremental parsing/ASTs; LSPs provide richer editor features (diagnostics, go-to-definition, formatting, etc.).
  • Conclusion: Tree-sitter and LSP are complementary; this project cannot replace LSPs in editors like Helix.

Meta: trend of ports & expectations

  • Some commenters note an apparent trend of “X reimplemented in Go/Rust” and question:
    • Whether these are meant to replace battle-tested C originals.
    • Whether they’ll be maintained long-term or are just short-lived “Show HN” projects.
  • A few users were excited initially but disappointed on discovering that the port doesn’t yet offer full Tree-sitter feature parity.