GO — Healthy across the board

• Last commit 3d ago
• 6 active contributors
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 79% of recent commits

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests}

XGo is a programming language compiler that transpiles English-like syntax to Go, enabling seamless interoperability with C/C++, Go, Python, and JavaScript/TypeScript ecosystems. The core compiler is written in Go (~1.7M lines) and transforms XGo source files (.xgo) into executable Go code, creating a unified multi-language development platform that reads like plain English but maintains production-grade performance. Monolithic compiler structure: ast/ contains the core AST transformation layer (ast/fromgo/ converts Go AST, ast/togo/ generates Go AST, ast/gopq/ provides query/traversal), cl/ houses the command-line compiler and test suites (_testc/ for C interop, _testgop/ for Go interop), builtin/ defines language builtins (doc.xgo). The cl/_testc and cl/_testgop directories serve as integration test harnesses for language features.

STEM educators, data scientists, and software engineers who want to teach or build systems using intuitive natural-language-like syntax while leveraging existing C/C++, Go, Python, and JS/TS libraries. Specifically targets developers seeking to lower the barrier to entry for systems programming without sacrificing interoperability with established ecosystems.

Actively developed with strong CI/CD (GitHub Actions workflows for go.yml, release-build.yml, codecov integration visible in .github/workflows/). The codebase shows mature tooling (.goreleaser.yaml, Dockerfile, comprehensive test structure under ast/goptest/), but XGo itself appears in mid-to-late beta phase — real production use exists but the language spec is still evolving (doc/spec.md, doc/spec-mini.md indicate ongoing standardization).

Single-language risk is low due to Go's stability, but XGo-specific syntax stability is moderate — the language is still defining semantics (multiple -testc and -testgop directories suggest active compiler testing). Dependency surface is small (markdown, goldmark for docs only in go.mod), but toolchain maturity depends on how many edge cases in AST transformation (ast/ast_xgo.go, ast/resolve.go) remain untested in real projects.

Active language specification work visible in doc/ (docs.md, spec.md, spec-mini.md, xgo-vs-go.md, contributing.md). The ast/fromgo/typeparams/ directory with go117 and go118 variants indicates ongoing support for Go's type parameter features. Makefile and all.bash/all.bat scripts suggest continuous build and release engineering.

Clone the repo, then use the Makefile: git clone https://github.com/goplus/xgo.git && cd xgo && make. On Windows, run all.bat. The Dockerfile indicates container-based development is supported. Go 1.22+ is required (from go.mod).

Daily commands: make in the root directory (see Makefile). For release builds, goreleaser (referenced in .goreleaser.yaml) is used. The build outputs xgo binaries that can transpile .xgo files to .go files, then Go's own toolchain compiles them.

• cl/compile.go — Core compiler logic that transforms XGo AST into Go code; entry point for the compilation pipeline that every contributor modifying language semantics must understand.
• ast/ast.go — Defines the abstract syntax tree representation for XGo; foundational for all parsing, analysis, and code generation stages.
• ast/resolve.go — Implements symbol resolution and type inference; critical for semantic analysis before code generation.
• ast/togo/goast.go — Transforms XGo AST to Go AST for final compilation; bridge between XGo semantics and Go runtime.
• parser/parser.go — Lexical analysis and parsing of XGo source files into AST; essential for understanding syntax rules and extending the language.
• README.md — Project vision, goals, and architecture overview; required reading for understanding XGo's design philosophy and interop model.
• Makefile — Build orchestration and test execution; shows how to compile, test, and validate changes locally.

Add Support for a New XGo Language Feature

1. Define new AST node type in ast/ast_xgo.go for the language construct (ast/ast_xgo.go)
2. Extend parser to recognize and parse the new syntax (update lexer/parser rules) (parser/parser.go)
3. Implement semantic analysis in ast/resolve.go to type-check the new construct (ast/resolve.go)
4. Add code generation logic in ast/togo/goast.go to transform to Go AST (ast/togo/goast.go)
5. Create test cases under cl/_testgop/{feature-name}/ with in.xgo and expected out.go (cl/_testgop/append1/in.xgo)
6. Run tests via make test and verify in.xgo → out.go transformation matches expected (Makefile)

Add a Domain-Specific Language (DSL) Extension

1. Create a new domain handler module under ast/ (e.g., ast/domaintext/ or ast/domainquery/) (ast/resolve.go)
2. Register the domain in the parser so XGo recognizes domain-prefixed blocks (e.g., @html, @json, @dql) (parser/parser.go)
3. Implement domain-specific parsing and validation logic to transform domain syntax into Go code (ast/togo/goast.go)
4. Add test case under cl/_testgop/domaintext-{name}/ or cl/_testgop/dql{n}/ with in.xgo and expected out.go (cl/_testgop/domaintext-json/in.xgo)
5. Verify domain test passes and generated Go code is correct (Makefile)

Improve Interoperability with Foreign Languages (C/C++, Python, JS/TS)

1. Study existing interop bindings and type mappings in ast/fromgo/ and ast/togo/ (ast/fromgo/gopast.go)
2. Define type conversion rules in ast/togo/goast.go to map XGo types to foreign language types (ast/togo/goast.go)
3. Add FFI glue code generator to create C/C++ extern declarations or Python ctypes bindings as needed (cl/compile.go)
4. Create integration test under cl/_testc/ for C/C++ interop or cl/_testgop/ for other bindings (cl/_testc/hello/in.xgo)
5. Test round-trip compilation and runtime linking with foreign libraries (Makefile)

• Go as implementation language — XGo targets and interoperates with Go; using Go for the compiler simplifies toolchain integration and leverages Go's strong standard library for AST manipulation and code generation.
• Multi-language AST representation (ast/fromgo, ast/togo) — Enables seamless FFI with C/C++, Python, and JavaScript/TypeScript by translating between XGo, Go, and target language type systems and calling conventions.
• Domain-specific language extensions (DSL blocks) — Allows embedding specialized syntax for JSON, HTML, SQL, regex, and templates directly in XGo, improving readability and reducing boilerplate for common domains.
• Test-driven code generation (cl/_testgop/) — Golden-file testing (in.xgo → out.go pairs) provides clear regression detection and acts as executable specification for the compiler's behavior.

• Compile XGo to Go instead of native bytecode/VM

  • Why: Leverages mature Go runtime, standard library, and build ecosystem; enables direct interop with existing Go packages.
  • Consequence: Adds Go compilation overhead; XGo cannot easily implement runtime features Go lacks (e.g., tail call optimization); deployment requires Go toolchain.

• Support multiple foreign languages (C/C++, Python, JS/TS) in one compiler

  • Why: Positions XGo as a unified ecosystem bridge, differentiating it from single-target languages.
  • Consequence: Increases compiler complexity, maintenance burden, and potential for subtle FFI bugs; requires expertise across multiple type systems.

• Use English-like syntax over mathematical notation

  • Why: Improves accessibility for non-programmers and domain experts; aligns with XGo's vision of lowering the barrier to software creation.
  • Consequence: Keyword namespace collisions with Go; parser must handle ambiguous constructs; larger lexicon than terse languages.

• Golden-file testing rather than runtime execution tests

  • Why: Fast feedback loop for compiler changes; clear AST transformation semantics; easy to debug code generation.
  • Consequence: Does not catch runtime errors or performance regressions; requires manual inspection of generated Go code.

• Does not provide a

The ast/fromgo/typeparams/ directory has separate implementations for Go 1.17 and Go 1.18+ (typeparams_go117.go vs typeparams_go118.go) — build flags or runtime checks determine which is used, so test across Go versions. The cl/_testc/ test structure assumes a C compiler (gcc/clang) is available in the environment for C interop tests. Symbol resolution in ast/resolve.go operates on scopes that must be pre-populated; missing scope setup will silently fail type checking. The ast/walk.go traversal patterns are critical — modifications to AST structure can break visitor implementations if not updated consistently.

• Abstract Syntax Tree (AST) Transformation — XGo's entire compilation strategy pivots on AST-to-AST transformation (XGo AST → Go AST); understanding tree traversal, node reconstruction, and annotation preservation is fundamental to all changes
• Multi-pass Semantic Analysis — ast/resolve.go implements a multi-pass type checker and symbol resolver; XGo must resolve symbols before code generation, requiring understanding of pass-based analysis architectures
• Scope and Symbol Table Management — ast/scope.go defines XGo's scoping rules and symbol tables; this controls variable visibility, shadowing, and package-level namespace resolution across Go/XGo hybrid packages
• Foreign Function Interface (FFI) — XGo enables calling C, Python, and JavaScript from a unified syntax; the ast/fromgo/ and ast/togo/ layers must coordinate FFI marshaling and type adaptation
• Code Generation via Go's ast Package — Rather than generating textual Go code, XGo rebuilds Go AST nodes (ast/togo/goast.go) then uses Go's printer; this ensures syntactic correctness and preserves formatting metadata
• Type Parameter Variance and Generics — ast/fromgo/typeparams/ handles Go 1.18+ generic syntax; XGo must preserve and transform generic type constraints through transpilation without loss of type safety
• Transpilation vs. Compilation — XGo is a transpiler (XGo → Go → machine code), not a native compiler; this two-stage approach trades startup overhead for ecosystem reuse and rapid iteration on syntax

• golang/go — XGo is built on Go's ast package and type system; understanding Go's compiler architecture is essential for XGo compiler hacking
• goplus/gop — Go+ is XGo's spiritual predecessor (same organization); Go+ pioneered data science-focused syntax extensions to Go, XGo generalizes this approach
• goplus/ixgo — iXGo is the interactive REPL for XGo (mentioned in README); complements the compiler with a playground for learning
• gopcode/vscode-goplus — VSCode language extension for Go+ that provides IDE support; XGo likely shares similar editor integration needs
• python/cpython — XGo's Python interop layer must interface with CPython C API; understanding Python's C extension mechanism is relevant for the ctypes/FFI implementation

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive test coverage for ast/resolve.go type resolution logic

The ast/resolve.go file handles critical type resolution and scope management but has no corresponding *_test.go file. Given that XGo bridges multiple languages (C/C++, Go, Python, JS/TS), robust type resolution testing is essential. This would catch regressions in cross-language interoperability and improve confidence in refactoring.

• [ ] Create ast/resolve_test.go with unit tests for scope resolution functions
• [ ] Add test cases for type parameter resolution (leveraging existing ast/fromgo/typeparams_test.go patterns)
• [ ] Test edge cases in cross-language type mapping and import resolution
• [ ] Aim for >80% code coverage on resolve.go

Implement missing test cases for ast/togo/goast.go Go AST conversion

The ast/togo/goast.go file converts XGo AST back to Go AST but only has a single basic test file (goast_test.go). Given that correctness of this conversion directly impacts generated Go code quality, this needs expanded coverage for edge cases like type parameters, complex expressions, and language-specific constructs.

• [ ] Review ast/togo/goast_test.go and identify missing test scenarios
• [ ] Add test cases for type parameter handling (Go 1.18+ syntax)
• [ ] Add tests for complex nested expressions and statement conversions
• [ ] Cross-reference with cl/_testgop examples to add integration-level test cases

Create integration test suite for domain-specific syntax (domaintext-* cases)

The cl/_testgop directory contains multiple domain-specific syntax test cases (domaintext-html, domaintext-json, domaintext-huh) but no unified test runner or documentation. These appear to be domain-specific extensions that need validation. Adding a test harness would ensure domain syntax remains compatible across releases.

• [ ] Create cl/domaintext_test.go to systematically run all domaintext-* test cases
• [ ] Add a test that validates each in.xgo file compiles to the expected out.go
• [ ] Document the purpose of each domain syntax extension in cl/README.md
• [ ] Integrate into the main test workflow (all.bash) to prevent regressions

• Add comprehensive test coverage for ast/commentmap.go — currently used for preserving comments during transpilation but has minimal test cases in ast/goptest/; writing tests for comment preservation across XGo↔Go conversion would be high-value
• Document the semantic analysis flow in code comments within ast/resolve.go — the file is ~1000+ lines with complex multi-pass analysis but lacks inline documentation; adding clear comments at section boundaries would help onboarding
• Create example integration tests in cl/_testgop/ demonstrating Python/JavaScript FFI patterns — currently the test directories focus on C and basic Go interop; examples showing how to call Python functions from XGo or vice versa would validate the multi-language promise

The XGo codebase has a generally solid security posture. No critical vulnerabilities were identified in the visible structure. Primary concerns are around dependency management practices, Docker build reproducibility, and potential exposure of repository metadata in container images. The codebase follows good practices with dependabot configuration and doesn't show obvious injection risks, hardcoded secrets, or credential exposure in the examined files. Recommendations focus on tightening Docker image builds, pinning exact versions, and establishing regular dependency scanning routines.

• Medium · Indirect Dependency on Outdated Goldmark — go.mod. The codebase indirectly depends on github.com/yuin/goldmark v1.7.8 (as an indirect dependency of github.com/xushiwei/markdown). While Goldmark is generally secure, this indirect dependency management could pose risks if not regularly updated. The transitive dependency is not directly pinned or managed in the go.mod file. Fix: Regularly run 'go get -u' to update dependencies and use 'go mod audit' (Go 1.22+) to check for known vulnerabilities. Consider adding 'require github.com/yuin/goldmark' directly if you need explicit version control.
• Low · Docker Image Base Not Using Specific Tag — Dockerfile (ARG BASE_IMAGE=golang:1.24-bookworm). The Dockerfile uses 'golang:1.24-bookworm' which relies on a floating tag. While 'bookworm' is a specific Debian release, the golang version could pull different patch versions. This reduces reproducibility and could introduce unexpected security patches or breaking changes. Fix: Use a specific digest hash instead: 'golang:1.24.0-bookworm@sha256:...' or at minimum pin the golang patch version explicitly (e.g., '1.24.0-bookworm').
• Low · Potential Git History Exposure in Docker Build — Dockerfile (COPY . .). The Dockerfile copies the entire repository context including .git directory by default with 'COPY . .'. This could expose sensitive git history, branch names, or commit information in the built image if not explicitly excluded. Fix: Use a .dockerignore file to exclude .git, .github/workflows, and other sensitive directories. Alternatively, use docker build with --build-context to limit what's copied.
• Low · Build Script Uses 'set -eux' Without Error Handling — Dockerfile (RUN << EOF section). The shell script in the Dockerfile uses 'set -eux' for strict error handling, which is good. However, the git ls-tree and xargs pipeline could fail silently if git is unavailable or paths contain special characters. Fix: Add explicit error handling for the git command, validate TARGETPLATFORM is set, and escape xargs arguments properly with -0 and find -print0.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/goplus/xgo shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live goplus/xgo repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/goplus/xgo.

What it runs against: a local clone of goplus/xgo — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in goplus/xgo | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 33 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of goplus/xgo. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/goplus/xgo.git
#   cd xgo
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of goplus/xgo and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "goplus/xgo(\\.git)?\\b" \\
  && ok "origin remote is goplus/xgo" \\
  || miss "origin remote is not goplus/xgo (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "cl/compile.go" \\
  && ok "cl/compile.go" \\
  || miss "missing critical file: cl/compile.go"
test -f "ast/ast.go" \\
  && ok "ast/ast.go" \\
  || miss "missing critical file: ast/ast.go"
test -f "ast/resolve.go" \\
  && ok "ast/resolve.go" \\
  || miss "missing critical file: ast/resolve.go"
test -f "ast/togo/goast.go" \\
  && ok "ast/togo/goast.go" \\
  || miss "missing critical file: ast/togo/goast.go"
test -f "parser/parser.go" \\
  && ok "parser/parser.go" \\
  || miss "missing critical file: parser/parser.go"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 33 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~3d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/goplus/xgo"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.