Dynamically-typed languages don't need generics just like they don't need interfaces. If everything is a duck and everything holds ducks, then you don't need generics.

The need for generics (or macro/template-based equivalents) naturally falls out of using a statically-typed language.

Disagree. Generics aren't just used to enable generic operations - they also provide clarity/documentation on what types are being passed around. As someone who spends a lot of time working on other people's (sometimes old and crufty) code, I find that invaluable.

That doesn't sound right. Take a look at the Enumerable trait in Ruby and tell me how many of those methods are expressible in Go: http://ruby-doc.org/core-2.1.0/Enumerable.html

I thought the whole point of picking a language like Ruby was to use a language in which you can describe what you want, instead of how you want it.

I'm a Rubyist who likes to play with Go.

Boy oh boy do I ever miss collection-level constructs like map and reduce in Go. I just don't think of them as 'generics' because I'm not very well-versed in statically typed languages.

I still bite the bullet and use Go anyway when it feels appropriate, because I can get fast type-checked programs with a reasonably quick prototyping cycle.

This is the reason that Go drove me to Haskell. These days I have fast type-checked programs with a more than reasonably quick prototyping cycle.

Plus after you get types down well enough, you can largely pretend you are using a dynamic language. For instance sometimes I write my functions, make sure they work right, check the type ghci says they are in the repl, and add the type annotation.

I think the amount of time I spend working on Other People's Stuff probably influenced my comment there. While I obviously use and appreciate generics for their enabling of generic operations, I tend to primarily love them for their documenting/strictness-enforcing aspects.