
Developer Preview of AWS SDK for Go - jeffbarr
https://aws.amazon.com/blogs/aws/developer-preview-of-aws-sdk-for-go-is-now-available/
======
darkr
This is great news. I've been using goamz for some coreOS presence/sidekick
containers, but found it quite lacking in quality, with a lot of missing
functionality.

The ability to build a container that clocks in at under 10MB (vs ~700MB for a
ruby aws-sdk stack) based on a minimal busybox container and a standalone go
binary makes it an ideal use case for presence or short-running cron-type
containers.

Also, the quality of the existing AWS sdk clients (especially with the most
recent major versions) has been excellent (at least in my experience with the
ruby and PHP libraries).

------
grose
We use this library at work and although keeping up with the constant API
changes is annoying, it works well. My main complaint is that this library is
very "un-Go". Everything is a pointer, even required parameters. I understand
that this is a result of automatic code generation used meet the needs of
various APIs with different semantics, but Go's lack of pointer literals makes
it hard to use (you can't write something like &"hello world"). So I consider
this a low-level library, and wrap it with more Go-friendly code.

The devs are definitely aware of this issue, and I thank them for getting rid
of map pointers. I don't think there's an easy solution.

~~~
goddardcm
Worth noting that they provide helpful functions for pointer-ization:

[https://github.com/aws/aws-sdk-
go/blob/master/aws/types.go](https://github.com/aws/aws-sdk-
go/blob/master/aws/types.go)

------
jvermillard
I hope they will rewrite awscli with it. Today it's quite painful to run it on
coreos (python/pip ran in a container)

~~~
fletchowns
Why is it painful?

~~~
kolev
Because if not run in a container, you should put things that upgrade Requests
in a venv at least otherwise you may end up breaking apt.

~~~
fletchowns
But shouldn't you always use a virtualenv anyways?

~~~
kolev
Project-wise? - Most definitely! Globally? - Not common practice, but also
preferred to avoid collisions.

------
andrewstuart
Quality, comprehensive client SDK code and documentation is a major
competitive advantage for any cloud computing platform.

It's good that Amazon seems at last to be taking SDK development seriously.

Amazon spent a very long time apparently not realising that AWS features only
exist if they are supported in client SDKs. Instead it went wildly ahead
building vast numbers of features for AWS, leaving behind a trail of
incomplete, out of date, poorly implemented, poorly tested, and poorly
documented client SDKs. The outcome being that when a new AWS feature was
announced, chances were you couldn't use it because it didn't exist in any SDK
for your programming language of choice - unbelievably frustrating to have to
read feature announcements knowing there was no way to use them. Features
aren't complete until all the client SDK's include code to drive it.

Amazon has fixed this as far as I can tell now has excellent SDKs for a wide
range of languages and appears to keep them up to date for the most part with
the features in AWS. The AWS SDK documentation is excellent and the SDK code
appears complete, tested and reliable. Woo hoo. Thanks be to the gods and
thanks to Amazon for comprehensively addressing this critical requirement.

So it is very gratifying to see that Amazon appears to be getting serious
about covering all the AWS features with modern, up to date, documented and
tested client SDK's.

In fact Amazon leaves Google far, far behind in the dust in the area of client
SDK quality. Google is so far behind Amazon in programming SDKs for its cloud
computing platform that its hard to see that they could catch up any time
soon.

Google is still scratching its head wondering why it is so far behind in cloud
computing and still without a clue that client SDK's matter. Google doesn't
even have a Python 3 API for its cloud computing platform, let alone an
official, complete, tested, documented and supported Go API. Google internally
uses Python 2 and Java so that's what its cloud computing platform primarily
supports. Google seems a little puzzled at the idea that you might not use the
same programming languages that it does. As for documentation, the Google
cloud computing platform documentation is worse than bad - it's often wrong,
which translates into hours and sometimes days or even weeks of wasted effort
(from personal experience).

------
stephen-mw
I checked this out when it was part of Stripe. I found it worked very well for
my limited use-cases.

Personally I just prefer python and boto for most of my AWS tools, but times
where I've switched to go is to take advantage of static compiling and
concurrency:

1\. Listing all of my AWS instances in all accounts in all regions (lots of
api calls!) 2\. Downloading/uploading large files via multipart API 3\.
Various server-side configurations

------
kolev
No credit or good words for Stripe where this originated?

~~~
jeffbarr
Both were supplied when we first announced the SDK! See
[https://aws.amazon.com/blogs/aws/coming-soon-aws-sdk-for-
go/](https://aws.amazon.com/blogs/aws/coming-soon-aws-sdk-for-go/)

~~~
kolev
Didn't see that, but I think it would be nice to give credit until the first
stable release.

------
NateDad
Very exciting to see an official SDK for AWS. We'll be looking into using this
for Juju.

