The node.js library [1] is incredibly well done. It's easily the best-documented node.js library I've ever seen.

[1] https://github.com/aws/aws-sdk-js

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

Flow does things like create global methods ( https://github.com/aws/aws-flow-ruby/blob/master/aws-flow/li... ) 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) 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 :)

The libraries are good.

The primary thing needed for ongoing success is relentless commitment to 100% coverage of the AWS feature set, with new AWS features supported when they become available, not "at some later date". Nothing worse than reading about some new (or old) AWS feature that effectively does not exist because it is not supported in the client libraries.

I like the first party libraries personally, because I find them to be very full featured.

> AWS' first-party client libraries are generally awful

Not a reasonable comment.