[ansible]

So I'll ask: What is it I need to read/work through in order to at least "get" Go and really understand its strengths (whether or not I end up liking it)?

As discussed elsewhere on this page, Go is not the most feature-rich language out there.

But it does have features that seem to help my solve my problems with a minimum amount of fuss. Like using interfaces liberally, instead of having to define classes. Having lexical closures is also nice.

If you're not working on an application that can benefit from concurrency, you may not see all the benefits of Go either.

What kind of problems were you trying to solve, and how did Go see heavyweight compared to how you'd solve the problem in some other language?

[wwweston]

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.

[ansible]

(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.)

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

[aangeles]

Regarding the sample code is "bson_*" is a bson code convention? I notice Mixed Caps [1]is the idiomatic code for go? TIA

[1]http://golang.org/doc/effective_go.html#mixed-caps

[ansible]

That stuff is from the bson Mongo package. I didn't want to pull it into this example, so that it could run on the playground. I replaced dots with underscores in that case.

[stanleydrew]

It's a painful exercise (entirely due to Apple, not Go), but we implemented an Apple Push Notification Service provider in Go that relies on several of its concurrency primitives.

I think implementing a simple HTTP proxy might also be a really good exercise, though I haven't done it.