I totally get why they are using structs rather than positional arguments, and pointers instead of literals.
Go doesn't have function overloading, so if they used positional arguments, they could never change the signatures in a backwards-compatible way. With structs, they can add new fields.
And the reason for the pointers is that Go doesn't have optionals or sum/union types. My own experience is that the lack of optionals, or some similar construct, is extremely annoying when writing clients and servers for APIs where parts of the requests and responses are optional. You have no choice but to dick around with pointers.
goamz is more idiomatic Go, but it's going to have a problem with backwards compatibility when Amazon changes their APIs. I'm with Amazon here, myself. goamz has a bunch of functions that take 4+ arguments, and given the lack of named argument support, that's when you really want to refactor your arguments into structs.
I'm all about passing structs and objects into methods and not make the arity too complex.
However, there's passing the struct and there's passing a pointer to the struct.
Also, if you look at the structs, you see that instead of just passing strings, they pass aws.string("some-string-value") which actually just takes the string and makes a pointer of it.
That's what I'm talking about when I say it's too verbose, it's just a lot of unnecessary things like this.
It's not unnecessary, though. In Go, a string cannot be nil, as you know; it is initialized to the value of an empty string. That's not true in any other languages, and even the Go AWS library cannot use that as a signal of intent, because you may have intended to use an empty string.
Granted, I don't know if there are any calls where an empty string is an actual valid parameter. But it seems Amazon is erring on the side of explicitness here.
I agree that the AWS library isn't ergonomic. But Go is forcing their hand, in my opinion.
Go doesn't have function overloading, so if they used positional arguments, they could never change the signatures in a backwards-compatible way. With structs, they can add new fields.
And the reason for the pointers is that Go doesn't have optionals or sum/union types. My own experience is that the lack of optionals, or some similar construct, is extremely annoying when writing clients and servers for APIs where parts of the requests and responses are optional. You have no choice but to dick around with pointers.
goamz is more idiomatic Go, but it's going to have a problem with backwards compatibility when Amazon changes their APIs. I'm with Amazon here, myself. goamz has a bunch of functions that take 4+ arguments, and given the lack of named argument support, that's when you really want to refactor your arguments into structs.