DMdmitriid·Nov 4, 2020
> and the HTTP package should not be polluted with assumptions about what (if any) data is being passed.
I'm not talking about the HTTP package itself. In Java and C# you do something along the lines of
// Java
CompletableFuture<PagedResult<Contract>> getContracts(...);
CompletableFuture<PagedResult<Client>> getClients...(...);
CompletableFuture<PagedResult<Book>> getBooks...(...);
// C#
JsonSerializer.Deserialize<PagedResult<Contract>>(responseBody);
JsonSerializer.Deserialize<PagedResult<Client>>(responseBody);
JsonSerializer.Deserialize<PagedResult<Book>>(responseBody);
And that's basically it. With Go you end up having fifteen identical PagedResult types for every single type that can be returned from the API because you can't parametrize anything:
// Go
type ContractsResult struct {
Result []*entitie
Read the rest
s.Contract
NextPageToken string
}
type ClientsResult struct {
Result []*entities.Client
NextPageToken string
}
type BooksResult struct {
Result []*entities.Book
NextPageToken string
}
> Or they use code generators, which is also pointed out in the article.
Code generators are just bandaid for glaring holes in the language. Worse still, I don't know if you can even specify code generating tools in your go.mod. For example, wire's installation instructions say "you need to install wire globally and have it on your $GOPATH" [1] So your go build will just fail mysteriously until you have all the necessary tools installed.
> Of course, anything more advanced would be greatly helped with generics
That... that is exactly what I'm talking about.
> Option types to avoid nil, Either types to replace the value/error tuples
Indeed. I forgot about those :) Yup, that would be a great use case for generics.
[1] https://github.com/google/wire