in my personal experience, go language "limitations" have always forced me to clarify and simplify my design. In the end, my code is way better than in my original intent.
I had to write seven or eight identical functions transforming some data because Go didn't have generics. Hardly a "better code".
They've now released generics, thankfully, but there are many places where there's unnecessary repetition and clunkiness because the authors "know better".
you couldn't make those data conform to an interface and have the algorithm work on the interface ?
in those scenarios i usually either work with interfaces, or composition (struct embedding), or as a final resort to codegen for things like generating bindings to database tables. the codegen is usually quite a good solution and makes debugging the generated code very straightforward, since it's all there, in the _generated folder, instead of in a temporary file generated by the compiler. it also makes the generator code a separate project, which IMHO is a better solution than using all kinds of macro and complex meta programmation directly in the final project.
Instead, you're focusing on fighting the language limitations on your way to build what you want ;)