> you're kidding yourself if you think having generics makes up for having to write your own AWS client in terms of productivity. It doesn't appear you need to

> you're kidding yourself if you think having generics makes up for having to write your own AWS client in terms of productivity. It doesn't appear you need to write your own AWS client - or at least, not from scratch: https://github.com/rusoto/rusoto https://github.com/rusoto/rusoto > Perhaps you see a different side to it from where you sit, but I do think #rust suffers from a certain degree of confirmation bias. From the outsider perspective of one who knows neither Go nor Rust well - Rust seems to acknowledge it has problems and gaps they're working on. Poor IDE support is one close to my heart. Compile times are another. Heck, I'm just rehashing the roadmap, aren't I. With Go I hear more about how they've intentionally avoided things in the name of simplicity, and having some opinionated stance on having one correct way to do things. I get the impression that Go will never have generics, by design. C# already covers most of the things I'd use Go for pretty well - I don't see much advantage to switching to Go. Rust, even in it's relatively untooled state, already has me seriously considering trying my hand at nontrivial projects in it. I've been chasing static analysis and appropriate annotations to catch threading bugs, data races, iterator invalidation, potential null derefs, etc. in C++ for some time, to great effect - and who knows how much time saved - in bugs avoided. I'm convinced it's a question of when, not if, I'll try switching over properly.