3 ms·
> 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
by dmitriid 6y ago
> 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 []*entities.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 https://github.com/google/wire