> I am far from being a Go expert but you can see this has been written by Java developers.

Hi! As of writing, I am currently the top code contributor to the AWS SDK for Go (NB: I've since moved out of Amazon). I've never written a day of professional Java in my life, but thank you for the compliment! Would you mind endorsing me for Java on my LinkedIn page? This will go far to getting me that enterprise Java job I never once dreamed of having!

But seriously, it's worth noting that the SDK was originally created by Stripe, and most of what you're likely referring to (struct inputs) worked in the exact same way when it was Stripe's codebase. As far as I know, Stripe is also not a Java shop.

I've heard this exact same comment at the release of almost all of the AWS SDKs I've been around for, so I'm not too surprised to see it again. I think this comes from people incorrectly assuming that (a) most Amazon developers only use Java (this is far from true), (b) that complex APIs are inherently "Java-like", and (c) auto-generated code is somehow evil, even though it yields fewer bugs, more consistent usage, better documentation, more performance optimizations (compare boto's issue tracker to Ruby, for instance, and count the number of defects).

The reality is that sometimes complex APIs are just what they are: complex. Goamz is "easier" because in most cases it completely ignores the complexity of the full API by only exposing a small subset of it. For many use cases this is fine, but I've spoken to plenty-a-customer who told me stories of trying to hack in extra API calls to Goamz when it couldn't do what they needed. That doesn't sound "easier" to me.

Unfortunately, when you're writing a generalized library meant to account for the simple and complex use cases alike, you can't optimize only for the users who touch a small portion of the API's surface area. You have to start with a base that supports all use cases. If AWS had released a library like Goamz, you would hear the other set of users complaining just as loudly that they can't do X with the SDK, talking about how poorly designed it is for them. Over time, you may see the Go SDK add specialized APIs to make certain simple use cases easier (just like has already been done in other SDKs), but this won't happen right away-- it requires a lot of effort to identify and prioritize those cases. The S3 upload/download managers and the DynamoDB marshaler abstractions are a good example of this. Instead of yelling into the wind, I would recommend opening issues to ask for similar simplified APIs for use cases that are genuinely complex with the current SDK. But note: they should be genuinely complex, not just "this takes 4 lines of code and it should only take 2".

> The usage is so verbose and you need to pass pointers around all the time. Even when it's clearly not changing the original instance (when passing by value would be enough)

Passing by value is not enough. Go cannot differentiate a string value of "" (or int value of 0) from one that was omitted by the user, which is why we (very painfully) had to make the decision to use pointers. Making this decision sucked; we literally spent weeks trying to whiteboard workarounds that wouldn't completely gut the core functionality of the SDK. Unfortunately, @lobster_johnson said it best when he pointed out that Go forced our hand here. The lack of overloading, named parameters, default arguments, nil-by-value, really are the reasons why it's just not possible to make this more elegant in Go. Using positional args, as pointed out, wouldn't even last 2 months before you would see breaking changes in the API calls for many of the AWS services. Things really do change that fast in the APIs, it's the underlying reason why all of the AWS SDKs moved to auto-generated code. It's the reason you now all get SDK updates on the day of the API release-- with way fewer bugs along the way. That's a good thing.

I think the team did a great job getting this out given the circumstances. Go is a solid language for app development, but it's not really optimized for generalized libraries. The lack of common language features (literally, the lack of "generics" for generalized interfaces) means you're effectively writing code with one hand tied behind your back. With a foreign keyboard layout of your evil coworker's choosing.