Go 1.6 is Released
Go has a lot going for it.<p>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:<p>1. It&#x27;s hard to tinker, mostly because it&#x27;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.<p>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.<p>I might just have memory problems, I acknowledge. :)<p>However, what would make sense is a go &quot;mode&quot; where it runs in a non-strict way, with what would ordinarily be errors being warnings.  A &quot;tinker&quot; or &quot;whirl&quot; mode, so to speak, that softened the requirements so one could get a better sense of what was happening before committing to a design.<p>An interpreter mode might also be quite valuable, to address this problem and the ones below.<p>2. Error propagation - I see the point of errors being returned and the lack of a &quot;throw&#x2F;catch&quot; style, and its benefit, but I feel it&#x27;s a lot of typing for marginal gain.  I usually end up with an error propagating a set of strings that ultimately conclude as: &quot;Database error: transaction error: processing error: http error: <i>reason</i>&quot;, 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.<p>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.<p>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&#x27;s virtualenv gets it right, by comparison.  A second but related problem is package versions.  Maybe I&#x27;m missing something, but making sure you get the latest semantically equivalent version (in the semver sense) was not apparent.<p>5. Package debugging: If you include a 3rd party package, and it&#x27;s broken in any way, it&#x27;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.<p>6. Automated testing: I&#x27;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.<p>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&#x2F;or inclusion of many third party packages.<p>I&#x27;ve not reviewed the 1.6 notes, so perhaps these are addressed to some extent there.<p>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&#x27;ve seen above give me pause before committing a team to the language – for the moment.