| I like functions as first-class values and closures. If they weren't present, I might well have bailed months ago. :) And from various experiences doing OO with other languages, I can kindof buy that Go interfaces are often 80% of what you want. Most of what I've been working on is a Rest API. Here's an example of a problem that felt like it should be something for which I'd be able to write an abstraction to deal with, but turned out to be challenging, at least as a n00b: https://groups.google.com/forum/#!topic/golang-nuts/JhsiiGHQ... (Incidentally, though I moved past my then really poor understanding of Go interfaces, I wasn't able to apply the respondent's answer or my new general knowledge to achieve the abstraction I was looking for, and settled for just grinding out the same code for the dozen entities/endpoints it applied to.) Concurrency: I suspect there's a bit that's hidden in some libraries we're using, and we may yet need to write our own code for some API requests that get processed offline, but I haven't had to explicitly write code for it yet. If you can think of a specific exercise that might serve to illustrate Go's outstanding concurrency strengths, I'd be interested to try it and compare efforts to another language or two. |
I definitely can't deny that using interfaces instead of regular OO classes takes some getting used to.
Though I don't understand why you had to grind out duplicate code for all the entities / endpoints though. I hacked up things a bit to get it to run on the playground, but as Jesse McNelis wrote, just passing the pointer to foo worked for the code you wrote.
http://play.golang.org/p/jNpK5CRBfv