Skip to content

ADR-010: Support C++, Go, and Java as Implementation Languages

Field Value
Date 2026-07-21
Status Accepted
Deciders Holger Zahnleiter
Supersedes —
Superseded by —

Context and Problem Statement

C++, Go, and Java were this generator's original three languages, chosen before this repository adopted the practice of recording architecturally significant decisions as ADRs. Adding a fourth language and project type (see ADR-009-support_react_typescript_frontend.md) prompted the question of why these three specifically — this ADR retroactively documents that long-settled decision rather than leaving it implicit.

Decision Drivers

  • Cover a genuinely different class of software per language, rather than three ways to write the same kind of program.
  • Prefer languages with mature, widely adopted tooling for build, test, and CI integration — this generator scaffolds that tooling, so immature ecosystems would show up as generator maintenance burden, not just a developer preference.
  • Prefer languages with a large enough user base that generated guidance stays broadly useful.

Considered Options

  1. C++, Go, and Java (the three actually supported).
  2. Add Python or Rust instead of, or alongside, one of the three.
  3. Support only one language, optimizing depth over breadth.

Decision Outcome

Chosen option: C++, Go, and Java, each covering a distinct class of software with mature, widely adopted tooling:

  • C++ — systems programming: embedded systems, game engines, high-performance computing. Chosen for its continued dominance in domains where garbage collection or a managed runtime is unacceptable.
  • Go — cloud-native services and CLI tools. Small binaries, fast startup, native cross-compilation for Windows/Linux/macOS on ARM64/AMD64 — a strong fit for microservices and developer tooling specifically.
  • Java — enterprise applications. Extremely wide adoption in business/enterprise software, with mature frameworks (Spring, Hibernate) this generator's service profile builds on directly.

Positive Consequences

  • Three languages, three genuinely different target domains — minimal overlap in when a developer would reach for one over another.
  • Each has mature CI/build/test tooling this generator can scaffold with confidence (Conan/CMake, go-arch-lint/golangci-lint, Maven/ArchUnit).

Negative Consequences / Risks

  • Popular languages outside these three (Python, Rust, C#, ...) remain unsupported. Accepted: supporting a language means scaffolding and maintaining its full guideline/CI/Makefile surface indefinitely, not a one-time addition — breadth has a real, ongoing cost.

Pros and Cons of the Options

Option 1 — C++, Go, Java (chosen)

  • Pro: Three distinct target domains (systems, cloud-native, enterprise), each well covered.
  • Con: Excludes other popular languages — acceptable given the ongoing maintenance cost of each additional language.

Option 2 — Add Python or Rust

  • Pro: Python is dominant in scripting/data/ML; Rust is a compelling systems-language alternative to C++.
  • Con: Neither was needed to cover a target domain the existing three didn't already address well at the time this generator's language set was chosen.

Option 3 — Single language, maximum depth

  • Con: Would leave systems programming, cloud-native services, or enterprise development entirely unaddressed — too narrow for a general-purpose scaffolding tool.
  • ADR-009-support_react_typescript_frontend.md — the same reasoning pattern applied to the generator's first frontend language/project type
  • internal/language.go — the Language enum this decision maps onto