goboot

Why

The Spring Boot developer experience — annotate a type, get it wired — without what usually comes with it: runtime reflection, classpath scanning, startup cost, or dependencies matched by strings. Every dependency is resolved with go/types at build time.

How

• A compiler pipeline — annotate → scan → analyze → model → graph → generate — each stage its own package.
• Annotations are // @Name(arg=value) comments with a real lexer and parser; each has a schema of allowed targets, argument types and defaults.
• Packages are loaded with go/packages; interface matching uses types.Implements on both T and *T.
• The dependency graph is sorted topologically for construction order, cycles are reported, and shutdown runs in reverse.
• The output is one generated wiring file meant to be committed and read. Generation is deterministic — the same input gives byte-identical output — and errors are diagnostics with source positions and stable GOB* codes, never panics.
• Interceptors such as @Transactional, @Traced, @Retry, @CircuitBreaker and @RateLimit are generated proxies; HTTP handlers and SQL repositories are generated too.
• Plugins (OpenAPI, AsyncAPI, extra SQL dialects, lint) are Go modules compiled into the CLI — no dynamic loading. goboot graph --format mermaid draws the graph.

It’s the compile-time answer to the runtime approach of godi. Documentation: zombocoder.github.io/goboot.

// @Service(name="userService", implements="UserUseCase")
type UserService struct{ repo UserRepository }

// @Transactional
// @Traced
func (s *UserService) Create(ctx context.Context, in CreateInput) (*User, error) { /* ... */ }

$ git clone https://github.com/zombocoder/goboot