kanna bets Go boilerplate belongs in your git diff, not inside a reflection library

A set of five Go code generators called kanna has been published on dev.to with an argument attached: the constructor wiring, type conversion and test-fixture code that most Go projects hand to a reflection-based library should instead be generated as plain Go and committed to the repository ^[0][1][2][3]. The trade is stated plainly by the author, who accepts a generation step and a generated file in every diff in exchange for wiring you can read in code review, see in git diff, and step through in a debugger, rather than behaviour hidden inside a library at runtime ^[2][14].

The set covers dependency injection, struct mapping, test fixtures, ORM row scanning and i18n, installs as independent go tools so a project can adopt just one, and emits plain Go with no runtime reflection ^[4][6][7]. There is no registration step; the input is the struct declarations and struct tags already in the codebase ^[5]. kanna-di treats any package-level function whose first return value is a named type, a pointer to one, or an interface as a provider, with a trailing error permitted, and finds them by scanning the packages it is pointed at ^[8]. A container is a struct whose fields carry a di tag ^[9]. Running go generate writes di_gen.go beside the source, holding a constructor that calls the providers in dependency order ^[10]. If anything in the chain returns an error, the generated constructor returns and propagates one ^[11]. Where several providers match a field, the generator refuses to choose and reports the field position with the candidate list ^[12]. A //kanna:container comment sets the constructor name, the return type, and whether a MustNew variant is emitted ^[13].

kanna-fixture writes one constructor per struct in the target package with every field pre-filled, so a test names only the values it cares about through setter functions ^[15][19]. Field names drive inference, so Email gets gofakeit.Email() and Name gets gofakeit.Name(), and a tag such as fake:"{number:18,65}" overrides the guess ^[17]. Every exported struct is covered with nothing to opt into, which the author presents as the reason fixtures do not fall behind the model ^[18]. Types beyond gofakeit, such as uuid.UUID, are handled, and the generator says so when the destination module does not yet require the needed package ^[20].

The honest accounting is that failures do not all land at compile time. Ambiguous providers fail at generate time ^[12]; generated code that no longer type-checks against changed structs fails at build, which is the actual substance of the claim against reflection ^[1]; and fixtures keep one runtime caveat, since generation is deterministic but the values are not, so a test needing the same data twice must call gofakeit.Seed ^[21].

Two caveats about the material itself. Only kanna-di and kanna-fixture are shown with generated output; mapping, ORM and i18n are named but not demonstrated ^[2]. And the write-up inventories the set twice, once as DI, mapping, fixtures and ORM, once with i18n added, which is a small sign of how settled the boundaries are ^[4][c4b]^[3].

Worth watching: whether the DO NOT EDIT files stay current under review pressure in a repository that is not the author's ^[22], and whether refusing to pick between candidate providers reads as safety or as friction once a container carries a few dozen fields ^[12].