I took care of that, caching structs metadata to limit useless repetitive introspections, and others simple stuffs. But of course if will always be slower than manually crafted code.
With Go the cost is ridiculous compared to round trips with database server and query execution. More productivity for just a bunch of CPU cycles. Of course each use case and constraints are different, they're is no universal rules.
Entity Framework... that is slow ! I don't know for EF Core, but EF6 is really a slow thing.
But code generation doesn't have to be painful. Consider https://gopkg.in/reform.v1, for example. It generates methods for your data types and uses then to cover 80% of typical usage and also does help you when you want to use SQL.
Code generation is always painful. It's yet another compiler add-on one has to add to a pipeline. Because now If I use your executable I have to manage your tool and its versions,it becomes yet another dependency. At least real/reified macros (that go lacks) need no third party executable . Code generation with third party tools means language fragmentation. Suddenly people add their own DSL on top of Go in form of a manifest. Suddenly Go executes instructions in comments and other horrors ...
Yes that sucks. So I have written / am writing my own code generation tool which runs only once and does not rely on any fancy instructions in comments. Ah yes ... maybe `go generate`. I hate a slow compiler.
With Go the cost is ridiculous compared to round trips with database server and query execution. More productivity for just a bunch of CPU cycles. Of course each use case and constraints are different, they're is no universal rules.
Entity Framework... that is slow ! I don't know for EF Core, but EF6 is really a slow thing.