4 ms·
I worry that a lot of developers who have been using languages like Java or C# see Go and immediately feel the need to point out that Go doesn't support languag
by kminehart 9y ago
I worry that a lot of developers who have been using languages like Java or C# see Go and immediately feel the need to point out that Go doesn't support language features that they've come to rely on, and so they see that as a weakness or a flaw.
With Go, you're getting a lot of high-level language features like anonymous functions, while also gaining the control that you're not able to get in higher level languages like Python or Ruby or Java.
I think this works out great for cloud computing, where performance is a major requirement, but the technology is expanding rapidly enough that a step up from C or C++ is very necessary.
A lot of the complaints I hear are related to abstractions, too, and I understand those to an extent. I also think that if you're complaining about the lack of generics, maybe you're not thinking about interfaces correctly. A perfect example is the beautiful simplicity that is the [`io.Reader`](https://medium.com/@matryer/golang-advent-calendar-day-seventeen-io-reader-in-depth-6f744bb4320b https://medium.com/@matryer/golang-advent-calendar-day-seven...).
So, whenever someone says something like the OP:
> As a simple language to wire pieces together, Golang is fine, but it really doesn't give you the tools (imo) to be productive for anything more complex than simple apps.
I take that as meaning, "I've never seriously used Go beyond writing a hello world app. It doesn't have the features I rely on to be productive, therefore I don't think it's a capable language for larger projects."
I will say though, dependency management in Go is hell. I wish Go had something like Cargo.
- aphextron 9y ago>I will say though, dependency management in Go is hell. I wish Go had something like Cargo. This is the number one thing that has kept me from going full on Go. The killer feature of Node was NPM, not Javascript. Unless Golang comes up with something comparable it will forever remain niche.
- cloverich 9y ago(NOTE: I am not a gopher) I thought godep was that? It's marked as suitable for production now, and I think official as of their next release. https://github.com/golang/dep https://github.com/golang/dep
- kminehart 9y agoIt is certainly a fantastic solution, and I definitely appreciate the work that Sam Boyer and the `dep` contributors do. There's a lot of "gotya"s with using dep though. One that gets me a lot is the fact that I like to commit my vendor folder, just for faster CI. So if I committed my vendor folder with a copy of "k8s.io/client-go", and then in a different project I imported a package from my vendored project, it would never compile until I removed my local copy of that "vendor" folder, since it's looking for that specific dependency ("my-project/vendor/k8s.io/client-go"). Not sure if I explained that super well.
- infogulch 9y agoOk, but why would you do that? Either just vendor it in the new project (copy-paste a directory) or download it to your gopath and import that. The nice thing is that you don't have to change the import when you decide to vendor.
- KishanB 9y agoI personally like glide more than godep
- kminehart 9y agoI think you misunderstand. If I have project A, which imports dependency A. I (for faster tests is the only real answer), decided to commit the vendor folder. Now, in project B, if I import a package of project A, which uses dependency A, it will look for that specific version of dependency A. Specifically errors like this: pkg/projectb/example.go:18:30: cannot use *w (type "github.com/dependency/pkg".Example) as type "github.com/project/a/vendor/github.com/dependency/pkg".Example It's not a big deal because if I just remove "github.com/project/a/vendor" from my $GOPATH then the problem is resolved. because of this, I guess my real complaint here is that "vendor" doesn't seem to be the right word. I'm really just looking for something to complain about.
- infogulch 9y ago