I think the problem with this approach becomes apparent when the database model changes, suddenly the API doesn't match the model anymore or the API needs to change. Both can be difficult problems leading to braking changes in the client(s).
Of course, for some rapid testing and simple personal projects this doesn't matter so much but for most other projects I think this might bite you hard in the future.
My experience with Go have been very positive. Once you get over the initial irritation of the error handling, I think it works perfectly fine. I have never been so productive as I can be when programming in Go. I’m sure there are technically better alternatives, but it has a very good balance between features, speed, standard library and multi platform support.
At least for the backend server tasks I use it for.
My biggest complaint has more to do with the new module system and tooling. The (not so) new Go Language Server is still very buggy and almost unusable in my opinion.
I was living in Chengdu for a year and I remember that I was surprised by the almost total lack of birds. In Hong Kong, where I am at the moment, there are more birds, but seems less than what we have back home in Northern Europe.
Yeah, I feel your pain, I’m Swedish living in Hong Kong, I don’t want my webpages or programs translated in either Swedish or Chinese, give me English please!
And as for the float parsing part, I have had to fix many bugs through the years where floating point numbers were stringified on a Swedish computer and then read back into float on an English computer, or vise versa. And sometimes a mix of the two where human input is involved. Easy to fix, but still a common problem.
To me the most complicated thing about formatting and parsing floating point numbers is usually if it uses decimal comma or decimal dot. It never seems to be what you expect if using a mix of different language operating systems.