3 ms·
I completely agree - the more I used it the less I liked it. I really enjoyed its implicit simplicity at first. The code I wrote had purpose and was clear, co
by SomeCollegeBro 11y ago
I completely agree - the more I used it the less I liked it. I really enjoyed its implicit simplicity at first. The code I wrote had purpose and was clear, consice, and easy to understand. However, as the codebase grew larger I really ran into the issues more people talk about. Specifically lack of generics. I was using reflection to simulate this, however my performance was terrible on large sets of data. I had to end up relying on a code generator, which seems to be the direction Go is heading.
Edit: Package versioning was another pain point, as someone mentioned below. Their built in package manager is almost too simple. As with anything simple, it's great at first but not so great when more complexities arise.
- pzduniak 11y agoThe package versioning issue has been solved in 1.5 for most of the popular use cases with the vendor experiment. Works just fine for me!
- drakenot 11y agoI hadn't heard about the vendor experiment. Is it now possible to point at individual tags/branches of a remote repository?
- lobster_johnson 11y agoThe new "vendor" system is basically that the Go compiler will look in vendor/ for your import before trying to traverse the GOPATH. This means you can manually download and freeze dependencies there. However, Go leaves the management of this vendor directory to you or some hypothetical helper tool — or with git submodules, for that matter. "go get", for example, still works just like before (ie., stores stuff in $GOPATH/src).
- bkeroack 11y agoIf you are using reflection, unsafe or even interface{} heavily, you almost certainly are not writing idiomatic Go. This will doom you to frustration and a poor experience overall.