Go Will Dominate the Next Decade
linkedin.com
linkedin.com
I'm a fan of go, but this post was way over the top. It reads like something a fan-boy would write about the latest Star Wars movie.
Go has hit a bit of a sweet spot in some ways. Static compilation, a good stdlib, decent performance and good tooling have all contributed to that.
It's also quite a shitty language in other ways. Dependencies are a mess. The lack of generics and associated functional primitives makes some code stupid and repetitive. Magical builtins like append() and delete() are a bad smell. Error handling is quite poor. There are others - the outcome being that it can be quite an irritating language to develop in.
It's obviously been successful in the areas cited because it's better than the other available options. Nobody really wants to use C(++) for things like devops tools, nor Java, Ruby or Python. That's a great use case.
I'm optimistic that some of the worst parts of Go will slowly be fixed as it develops, and will make it much more pleasant to use. Until then, I'm not confident it's going to dominate outside of those areas it's currently used. Of course, I could be entirely wrong… I guess time will tell.
Obligatory Simpson's Disco trend forecast meme:
http://www.ivystreetstudio.com/wp-content/uploads/2010/04/di...
Perhaps that is why Go seems to be dominating. In your little bubble.
So, I'll ask here.
1. What's the deal with GOPATH? 2. How do I structure my projects? 3. I would like to make command line tools that run on many platforms. Where do I get started?
2. a. All of your Go source MUST exist somewhere underneath $GOPATH/src. Otherwise, the build tooling simply won't work. [1]
2. b. If your Go project is hosted on e.g. GitHub, it needs to exist at the path $GOPATH/src/github.com/bphogan/reponame. Do not attempt to work around this convention. [2]
2. c. Finally, whenever you import a package -- even if it's a subdirectory of the same project/repo that you're working in -- you need to specify the complete import path. That is, import "github.com/bphogan/reponame/mypkg". [3] This has implications for forks, which can be dealt with.
3. a. Create a new repo on GitHub, write a `package main`, and commit/push. Now, anyone with a working Go installation can `go get github.com/bphogan/reponame` and your commandline tool will be downloaded, compiled, and placed in $GOPATH/bin for them to use.
3. b. As of Go 1.5, you can cross-compile binaries for platforms other than your own, by setting the GOOS and GOARCH environment variables before the `go` command. For example, if `go build` produces a binary for your current OS/Arch, then `env GOOS=linux GOARCH=amd64 go build` will produce a binary for linux/amd64.
---
[0] In reality, GOPATH is actually like PATH in that it can contain multiple delim-separated paths. This has consequences that you need to think through. https://golang.org/cmd/go/#hdr-GOPATH_environment_variable
[1] For the most part. `go run` works anywhere, for example, but you shouldn't be using that as part of your regular dev cycle. You can also compile and link manually, if you really want to.
[2] Strictly speaking, you can get around this requirement, with a latticework of clever tricks and hacks. Some people like to have their repos represent their own GOPATH, and play games with setting a new GOPATH for each new repo/project. I can almost guarantee you that if you start doing this, you will become very frustrated with the language and probably give up on it.
[3] Relative imports, like import "./foo", are technically allowed by the compiler, but are widely considered to be a mistake outside of one very specific circumstance having to do with test packages.