6 ms·
I was hoping this article would have more substantive advice for new Go developers. It seemed to mostly have very general advice that applies to most other lan
by drakenot 11y ago
I was hoping this article would have more substantive advice for new Go developers. It seemed to mostly have very general advice that applies to most other languages like: "Don't try and write language X in language Y. Keep complexity down by not over using complex language features."
I'm writing my current hobby project, a podcast fetcher, as my first project in Go.
The project has been going generally well but there have been a few annoyances so far:
* Why are you not able to easily version git dependencies? Go's solution to this problem is to tell you to create an entirely new git repository for each major version. Really? If they didn't want to go full blown dependency versioning with something like CocoaPods, they could at least let you specify a git branch or tag.
* The db.Sql abstraction does not support multiple result sets. Therefore database drivers, like the popular mysql driver, don't support multiple result sets. This really limits the kinds of stored procedures you can call.
* The debugger support is bad. I have to fall back to using print statements for most of my debugging.
- threeseed 11y ago"You can make it work, but there is a reason why the Go team chose not to implement that. And, no, it’s not that they are lazy." One of the many wonderful comments in there. Those annoyances you listed aren't Go's fault. It's yours.
- robryk 11y ago> Why are you not able to easily version git dependencies? Go's solution to this problem is to tell you to create an entirely new git repository for each major version. Really? If they didn't want to go full blown dependency versioning with something like CocoaPods, they could at least let you specify a git branch or tag. Take a look at gopkg.in[1]. This is a service that makes branches in other repositories go-gettable. Eg. go getting gopkg.in/foo/bar/v5 will download branch v5 from github.com/foo/bar. This seems to me to be a way of dealing reasonaly well with the issue -- the go get tool itself doesn't need to understand anything at all here. [1] http://labix.org/gopkg.in http://labix.org/gopkg.in
- gcv 11y agoA nasty workaround for a problem which should not exist in the first place. Ditto dependencies on private repositories.
- IvarTJ 11y agoI personally don't see having the version in the package address particularly more nasty than specifying it in the project file, as in Maven, which I have been dealing with lately. One problem I imagine is that when migrating to a new version of a library, the address has to be updated in each file the library is used in, with potentially catastrophic consequences if any one file is forgotten. A grep seems wise in that case. Would you argue that there are more robust solutions in the Haskell ecosystem? What scheme do you prefer?
- drakenot 11y agoI don't think the issue was with specifying the version in the package address. It is that you need to use a 3rd party, remote service, to redirect your requests to the appropriate git repo and branch. This is because Go doesn't support specifying branches/tags itself when specifying a git dependency. This workaround is contingent on gopkg.in people keeping their service maintained and running. If they went down, all your dependencies would break.
- commentzorro 11y ago> A nasty workaround for a problem which should not exist in the first place. In Go I believe they use the term "idiomatic." ;-)