

Coming Soon – AWS SDK for Go - urlgrey
http://aws.amazon.com/blogs/aws/coming-soon-aws-sdk-for-go/

======
bgentry
It's awesome that they reached out to the authors of a promising community
project[1] and adopted that, rather than building their own project from
scratch. AWS' first-party client libraries are generally awful, but I think
this one stands a chance to be very good.

Also, the current situation with goamz is truly horrific. There are multiple
independent forks of the original Canonical Launchpad-hosted version, each
with their own subtle differences in usage, interfaces and feature support.
None of them feel like idiomatic Go.

It really would be unlikely for this now AWS-supported project to end up doing
worse than the status quo.

[1] mainly Coda Hale from Stripe, where the project originated:
[https://github.com/stripe/aws-go](https://github.com/stripe/aws-go)

~~~
jeffbarr
> AWS' first-party client libraries are generally awful

Do you have some feedback that I can pass along to the AWS SDK team?

~~~
bgentry
Sure, but going from memory on this :) As far as the Ruby SDK, my opinions are
mostly based on how things were 2-3 years ago, when I wrote it off entirely
after inheriting several large projects that made heavy use of it.

In the past, it was difficult (impossible?) to figure out how it worked by
reading the code. That's highly unusual for a Ruby library. It felt like a
generated library, not like Ruby. When something wasn't working as expected
(which happened often), it was difficult to figure out what was going wrong
and why.

As a heavy AWS user, I've felt much more comfortable using Fog, even though I
only really use its AWS provider. That's true even though I didn't even get to
take advantage of Fog's multi-provider abstractions (basically just using it
to make raw AWS API calls). Hopefully that's all in the past and I should give
it another look the next time I'm doing that stuff in Ruby. Fog also gave
_much_ better control over a lot of the details that are important when doing
stuff in production, like timeouts and keep-alive settings.

The 2nd example that comes to mind is the AWS Flow framework for Ruby:
[https://github.com/aws/aws-flow-ruby](https://github.com/aws/aws-flow-ruby)

Flow does things like create global methods ( [https://github.com/aws/aws-
flow-ruby/blob/master/aws-flow/li...](https://github.com/aws/aws-flow-
ruby/blob/master/aws-flow/lib/aws/decider.rb#L60) ) and its DSL abstraction
just doesn't feel right. It tries too hard to make it feel like you're just
running Ruby code, and it's tough to determine how it uses SWF under the hood.
It's such a large abstraction on top of SWF that it basically means you can't
write parts of your app in anything other than the Flow frameworks for Java or
Ruby. But then, the other major SWF framework I've seen
([https://github.com/sclasen/swf4go](https://github.com/sclasen/swf4go)) also
locks you in. So maybe it's just a shortcoming of SWF that it's not usable
without a big abstraction layered on top of it?

From what others are saying, it sounds like the newer stuff is in much better
shape. That's very encouraging!

Regardless, I think you've made a great decision in taking over aws-go. I have
very high hopes for its future :)

~~~
jeffbarr
Thanks, this is incredibly helpful. I will pass it along to the team in the
next 45 seconds.

~~~
bgentry
How well do you know the SNS team? :)
[https://twitter.com/blakegentry/status/539873715446878209](https://twitter.com/blakegentry/status/539873715446878209)

~~~
abhinavg
I believe you need to enable "Raw Message Delivery" in the subscription
attributes for that subscription for it to deliver raw JSON content instead of
wrapping your message in an envelope like that.

------
bkeroack
There exists a third party library called goamz which has been forked all over
the place when people have needed to add random features not found in the
original version. It works well but hopefully you don't need a set of features
that require you to import multiple versions.

Hopefully Amazon's version will be comprehensive and idiomatic.

~~~
Rapzid
True. The "big" players that forked it couldn't be _explicatived_ to work
together so the project became seriously fractured. I'm hoping this will move
swiftly through experimental to release, and that the generated nature doesn't
produce yucky to use implementations.

------
sciurus
If this has better coverage of AWS features than their goamz fork, I hope
Hashicorp will switch to it in Terraform. I'd love to use Terraform but too
much of what I use Cloudformation for isn't there.

[https://github.com/hashicorp/terraform/issues/28](https://github.com/hashicorp/terraform/issues/28)

------
fideloper
I'd love to see their CLI tool converted to Go - not because I have anything
against Python, but because installing Go binaries is so easy.

(Would there need to be any dependencies to install?)

~~~
artifaxx
Good point, I look forward to seeing how this fits together. It would
definitely add to the value of AWS for me.

------
enahs-sf
This is great! I can now unify a lot of my workflow and not have to use ruby
as a glue layer between applications and operations. It's great to see the Go
ecosystem improving! I think in a few years, it may become the defacto tool of
systems programmers.

~~~
shanemhansen
Frankly go isn't my favorite glue language (and I'm one of the relatively few
people who's been doing go full time for a couple years). I currently prefer
python for that kind of stuff, or sometimes bash.

However it's certainly possible to use as a glue language. I've talked to some
folks at DO who just install go on machines and `go run` scripts.

~~~
enahs-sf
For small internal projects, I typically find that I end up writing the
program and compiling it; It just builds up my developer toolchain from the
command line to do my bidding. Also, these are all managed under source
control, so my co-workers can also take advantage.

------
djhworld
Wow that moved quick, I remember reading about this library a month or so
back.

Glad to hear Amazon have formally adopted it as canonical!

------
moorage
I maintain [https://github.com/AdRoll/goamz](https://github.com/AdRoll/goamz)
FKA [https://github.com/crowdmob/goamz](https://github.com/crowdmob/goamz) ,
if anyone has any questions.

------
marcosnils
aws golang sdk's have been around for a while and I've found several other
which are well tested and maintained such as
[https://github.com/goamz/goamz](https://github.com/goamz/goamz). It's awesome
that aws finally decide which library they're officially adopting but I found
frustrating that the library is poorly tested and it will take while until it
becomes the official. It'd be great if all the other sdk's contributors start
working on the same project.

~~~
djhworld
The goamz project is an embarrassing mess, so many forks.

~~~
Bjartr
But anyone can fork any project on github willy-nilly, for whatever reason
they want, it's not something that's really under the control of original
project.

~~~
djhworld
True but they're all diverging away from one another, all under the "goamz"
name

~~~
Bjartr
like a great many projects on github. Popular/mainstream projects on github
have thousands of forks.

------
kid0m4n
This is great news indeed. Why could this not have come 8 months ago? Back
then, it was quite disheartening to see the replies from AWS team about Go
support.

------
namelezz
Recently I have heard so many good stories about Go although my impression of
Go gradually decreases due to unstable development tools and unfriendly
debugging tools. FYI, I use IntelliJ to write Go.

~~~
wtf_is_up
Sublime Text + GoSublime plugin is my favorite setup.

~~~
namelezz
Sublime Text + GoSublime was my first try but then I kept getting //GsDoc: no
docs found. At that time, my solution was using Sublime Text + GoSublime +
Godef. I still could not find a good debugging tool though.

Godef: [https://github.com/buaazp/Godef](https://github.com/buaazp/Godef)

Others also have this issue with GoSublime
[http://stackoverflow.com/questions/21832288/gosublime-go-
to-...](http://stackoverflow.com/questions/21832288/gosublime-go-to-
definition)

------
mrKlin
This is very promising for the Go future as more mature packages will be
available from big companies

------
andrewstuart
How about a Rust SDK for AWS?

