>The constant use of generated code is another real pain point, particularly when I am writing business logic that needs to operate on generated types for which

>The constant use of generated code is another real pain point, particularly when I am writing business logic that needs to operate on generated types for which there is no interface available that does what I need (and why would there be? how would the library/codegen-tool author know all the permutations of business logic that might be out there?). Not sure what you mean here. Is there a particular codegen tool you found lacking? >The introspection capabilities (reflect package) are quite obtuse and error prone (basically requiring 100% test coverage because you lose nearly the entire type system), yet absolutely critical to implementing anything notably complex with Go. Ah, the lack of generics. I haven't really written any particularly large projects, where have you had to use reflection when working with go in your projects? I hope my questions don't come across as dismissive. I think the typical go response to your complaints are "it wont come up" (a YAGNI variant), so I'm always interested to hear about the cases where that argument fails.