
The AWS SDK for Go is now 1.0 - GeneticGenesis
https://aws.amazon.com/blogs/aws/now-available-version-1-0-of-the-aws-sdk-for-go/
======
avitzurel
I've used the SDK in the past (before the 1.0).

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

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).

If you compare it to another lib like goamz you can clearly see how easier it
is to use comparing to the Amazon SDK.

There's also an issue from June 4 that discusses this:
[https://github.com/aws/aws-sdk-go/issues/265](https://github.com/aws/aws-sdk-
go/issues/265)

In my lib I ended up going with goamz, it was much simpler to use and required
much less boilerplate.

~~~
AYBABTME
The original code was autogenerated, which is why the style was very terse and
verbose. It's still like that:

[https://github.com/aws/aws-sdk-
go/tree/master/models/apis](https://github.com/aws/aws-sdk-
go/tree/master/models/apis)

The fact that it feels very Java-esque comes from two things, in my mind:

    
    
       - the AWS API has Java-esque RPC calls
       - the request/response paradigm is easier for 
         code generation
    

Personally, I don't like the style of the SDK, but at least it's maintained by
AWS; you can always wrap the parts you use to get a nicer interface.

~~~
omaranto
What do you mean by "terse and verbose"?

~~~
AYBABTME
Ugh I failed at english ='(

I mean, "terse" in the sense that it is very mechanical, raw, not very
elegant. Verbose in that you need to type a lot of characters, or read a lot
of instructions, to understand the meaning.

~~~
swuecho
raw instead of terse?

I am not native in English too. anyone can think of a better word.

~~~
erose1
Maybe "inelegant" or "rough".

------
donatj
aws.String just to get a pointer to a string rubs me the wrong way. I guess
that lets it be nillable but I still don't like it.

I have been watching it's development fairly closely, seeing their strange
decisions, and hoping they would rectify them. They haven't, and as a whole
the API is not written "the Go way". It's written like they are fighting the
language.

I assure you that in Go there are better solutions to much of this. I pray V2
to be better but if it's anything like their other SDKs they'll avoid breaking
changes to the interface until its simply no longer reasonable.

Their PHP SDK is largely powered by magic getters, setters and method calls,
and the methods therein are largely defined by a file describing the API. This
works but is hardly ideal particularly for static analysis. I was at able with
a PR to talk them into putting the method hints back at least.

You can really tell they were missing the magic in Go and working very hard to
try to make it work in a somewhat similar fashion.

------
andrewstuart
Full points to Amazon for not treating client SDK's like some sort of third
class afterthought. And double points for not just palming off client SDK
responsibility to "the open source community".

A cloud feature does not exist unless it is supported by the SDK that you
program with.

~~~
andrewchambers
The crappy design of this library screams after thought. The google cloud go
sdk is far better.

------
krishnasrinivas
[https://github.com/minio/minio-go](https://github.com/minio/minio-go) is a
nice S3 Client library in Go

------
monksy
Now introducing random 500s in Go!

------
elcct
Great. I've been using it for the past few months. Documentation is terrible
and there was quite a lot of breaking changes, but other than that it works...
so I am okay with that.

------
DeveloperExtras
Yes, but does it play Doom?

