[icey]

I've spent the past couple of months working with Go, coming from a mostly C# and Python background. One of the attractions to the language for me is that it's straightforward to pick up. Because there aren't a lot of "fancy" features in the language like Linq or list comprehensions, it's easy to dive into a block of code and figure out what's going on without requiring a lot of background knowledge.

The language eschews some brevity in exchange for clarity, which gives me a lot of confidence that I can take a good developer from any background, give them a week and feel like they've got a decent chance of acquiring the knowledge they need to work with the language.

The newness of the language means that there isn't a huge ecosystem of libraries available, BUT the standard lib is pretty damn great, and there are more and more people coming to the language every day.

My favorite thing about go is it's overall sense of boringness - Go code seems very predictable. There's a culture of digging into the source throughout the community, and tools like go fmt & go vet ensure that most code looks similar.

It'd be worth spending a week with it to write something useful to get a sense of whether or not you truly like it, but my experience has been very positive so far.

[StavrosK]

My problem with it is how frustrating it is to write when you're not very familiar with it, but I suspect that's more of a generic complaint about learning a new language rather than soecifically about Go. Every line I write, I go "argh, I wonder if this is the idiomatic way to do this" and I get frustrated a lot.

I love the features, though, especially the concurrency ones. It was conceptually trivial to write a multicasting TCP proxy in it.

[icey]

I had the same problems when I first started learning the language, and while I'm certain I've got a lot more to learn I found that making a habit of reading lots of source code made a huge difference.

After a little while you start thinking about "can this code be clearer? Are the intentions obvious?" and that makes the code much easier to write.

Go is incredibly easy to refactor, so instead of worrying about being exactly right, you can focus on "is this easy to reason about?". My experience has been that this process will get you very close to idiomatic code on its own.

[StavrosK]

I'm not so much frustrated about being exactly right at a high level, since I am experienced enough with other languages to get the general architecture down correctly. It's more like "How do you declare a slice of channels of channels of ints? Do you make() it or not? If you want to pass a channel, do you pass a pointer or not? How do you pass and reference a pointer? Do you use make in the outermost scope? How do you iterate over a channel but still handle a close?"

It's stuff like that, things I already know how to do in other languages but whose syntax eludes me in Go. I think all I can do is power through it until I gain some familiarity, though. Good thing the people in the IRC channel are amazingly helpful.

[jebblue]

>> Because there aren't a lot of "fancy" features in the language like Linq or list comprehensions

Not yet perhaps.

[NateDad]

The team working on Go regularly rejects proposals that make the language more complex just to save a few keystrokes. They and most experienced Go programmers value the simplicity of the language. Syntactic sugar is routinely rejected out of hand. The increment operator (++) isn't even allowed as an expression because it is too easy to make confusing and error prone code. (you can still use it as a statement, you just can't do like foo[a++]). I wouldn't be worried about the language increasing in complexity much. :)