3 ms·
For (1), I'd highly suggest using 'goimports' (my editor's fmt-on-save uses 'goimports' by default). It will remove and add non-referenced imports as needed.
by zenlikethat 11y ago
For (1), I'd highly suggest using 'goimports' (my editor's fmt-on-save uses 'goimports' by default). It will remove and add non-referenced imports as needed. Also, quick prototyping is partially what the underbar (_) notation is meant for in variable assignments.
As for (2), I feel it's more of a consequence of programmers not using error types to its advantage. Since Error is an interface it allows for an absurd amount of flexibility (e.g. bundle up a whole bunch of information into one error and send it back) and typed errors, both of which are excellent for testing and debugging.
As for (3), I usually rely on printing output (github.com/davecgh/gospew is quite useful). To get a stack trace just calling panic() in the offending code area will suffice.
No arguments on (4) - it could be better - but I think support for vendoring is a good step, and the maintainers seem to be taking it slow and getting it right.
On (5) -- if you go get the package it's available in GOPATH and/or it's usually vendored, so you can just go edit it in place (including debugging statements if you need more insight) without needing to know any magic $X_PATH rules -- I see this as a huge advantage. Furthermore, go get-ed code is each in its own version control repo, so sending patches back upstream is (generally) easier than ever.
Anyway, hope I don't seem argumentative (everyone has different tastes), but maybe some of these suggestions might help you a bit with your language peeves.
- bmh_ca 11y agoGreat feedback, thank you. On (1) Great suggestion, looks good. On (2) I'm probably biased by having spent a lot of time with Python and Javascript and bound to some preconceived notions of how one should deal with exceptions, so perhaps I give Go a harder time than I should for my failings and not its. :) On (4) I hope they get it right; packaging can definitely make-or-break the system. On (3) and (5) I found these techniques could/did-not work when testing Go App Engine. Editing the third party source had no impact, even after restarting App Engine, re-running tests, and deleting the .a files. I'm sure it's just another trick, but I couldn't find it so I eventually just gave up ... hence it being in my list of concerns. Thanks for the feedback, I appreciate the suggestions. Cheers