Actually it's even easier in Go with struct embedding:
type SmallerThing struct {
Id int
Login string
IsAdmin bool
}
type UserController struct {
SmallerThing
OtherField Whatever
OtherField2 SomethingElse
}
In principle this could break down if you need super, super complicated non-overlapping mappings, in practice I have yet to need that.>you have a model with 20 fields and need to create a tiny slice of it (with let's say three fields), you need a few lines of boilerplate: create a record with those fields (1-3 LOC):
>create a mapper for it:
> ...
>Go developers usually "don't need these complications", so this is just another self-inflicted problem.
In Go:
type DTO struct {
A, B, C string
}
Somewhere in your API layer: // copy the fields to the DTO
return DTO{A: o.A, B: o.B, C: o.C}
I fail to see where the "self-inflicted problem" is and why it requires a whole library? (which seems to require around the same number of lines of code at the end of the day, if you count the imports, the additional mapper interface)
It also handles nested/recursive entities, nulls, etc. It's also using codegen, not reflection, so performance is exactly the same as if you had written it by hand, and the code is easy to read.
https://mapstruct.org
Go developers usually "don't need these complications", so this is just another self-inflicted problem. Or maybe it's solved, look around.