Does this mean that SourceHut will become completely written in Go? Amazing news if so!
replies(1):
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?).
The sql library has some fairly annoying documentation, e.g.
> Scan implements the Scanner interface.
https://golang.org/pkg/database/sql/#NullBool.Scan
> Scanner is an interface used by Scan.
https://golang.org/pkg/database/sql/#Scanner
There is only really one concrete example of how to use Scan on the godoc page.
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.
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.