Go has a lot going for it. That said, there were a few points I noted, based on a recent go I gave it (pardon the pun), at least in relation to my style of dev

Go has a lot going for it. That said, there were a few points I noted, based on a recent go I gave it (pardon the pun), at least in relation to my style of development for this project: 1. It's hard to tinker, mostly because it's fussy about what variables are defined or used. This is a strength in the usual course, but when one is trying to posit what a poorly documented 3rd party API is doing it can be a serious pain. By tinkering, I found that I often had to comment out or uncomment lines, or handle or ignore errors. There was a lot of flipping up to the beginning of the file. I would spend so much time fiddling with the lines that I would at times forget what I was even trying to do. I might just have memory problems, I acknowledge. :) However, what would make sense is a go "mode" where it runs in a non-strict way, with what would ordinarily be errors being warnings. A "tinker" or "whirl" mode, so to speak, that softened the requirements so one could get a better sense of what was happening before committing to a design. An interpreter mode might also be quite valuable, to address this problem and the ones below. 2. Error propagation - I see the point of errors being returned and the lack of a "throw/catch" style, and its benefit, but I feel it's a lot of typing for marginal gain. I usually end up with an error propagating a set of strings that ultimately conclude as: "Database error: transaction error: processing error: http error: reason", which is to say: equivalent but less information than a stack trace would give. I see the mandatory error acknowledgement simultaneously as a strength and a waste of time, and I admit being on the fence about it. 3. The next point I am not on the fence about: Debugging. It is not apparent how to get a stack trace, and the best option looks like including a third party application that generated errors. For the obvious and reasons below, this is a problem. 4. Package management: This was fussy and could be time-consuming. It is not apparent to me why one needs a GOROOT and a GOPATH. I think Python's virtualenv gets it right, by comparison. A second but related problem is package versions. Maybe I'm missing something, but making sure you get the latest semantically equivalent version (in the semver sense) was not apparent. 5. Package debugging: If you include a 3rd party package, and it's broken in any way, it's a veritable quagmire to identify and fix the problem. My experience was that the best way to debug a third party package was to block and copy all its bits and then debug it as a local source in your own. Obviously this is bad for a long number of reasons, and I might be missing something, but no more apparent option appeared when I investigated on how to tell what is even happening inside third packages. 6. Automated testing: I've not seen a test runner that reloads when source files change, particularly one that might be used with goapp from AppEngine, meaning go auto-testing can be quite a bit of patient thumb-twiddling as the binary reloads. Which is all to say that there are some concerns about developing a larger project in this language, particularly if there is quite a bit of complexity that needs lots of testing or potential debugging and/or inclusion of many third party packages. I've not reviewed the 1.6 notes, so perhaps these are addressed to some extent there. In any case, none of the issues above is insurmountable, and overall I give the Go design a lot of credit for experimentation and interesting choices, but the issues I've seen above give me pause before committing a team to the language – for the moment.