Hacker News new | past | comments | ask | show | jobs | submit login
Go Will Dominate the Next Decade (linkedin.com)
13 points by bsg75 on Sept 23, 2015 | hide | past | web | favorite | 10 comments



Apparently go excels with programmers who like to "get shit done". If you program in some other language, you believe in "total bullshit" or the "hot new framework".

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.


This article literally says that "your business will die" if it isn't using Go. I think we can all agree that's a little over the top.

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.


It's an obvious desperate attempt to get attention by making a hyperbolic statement. It's sad to see that it is working.

Obligatory Simpson's Disco trend forecast meme:

http://www.ivystreetstudio.com/wp-content/uploads/2010/04/di...


I think the author is in a Go bubble and just doesn't realise it. There is much hype and hyperbole here, but it seems like the author thinks what the world uses is the same as what those in his personal bubble use.


> I talk to a lot of people about Go every single day.

Perhaps that is why Go seems to be dominating. In your little bubble.


I looked at Go a couple years ago now and haven't gone back for a bit because I could never wrap my mind around how to get started. Every Go developer I know just replied with "It's easy. Duh. Just read Effective Go."

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?


1. `export GOPATH=$HOME` -- or, `export GOPATH=$HOME/go` if you insist. [0]

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.


Thank you kindly for this concise and well explained answer. I truly appreciate the time you took with your explanations.


Quick note on 3.b - Go 1.5 didn't introduce cross compilation, that's been around for much longer.


Yes, but before Go 1.5 you had to build the toolchain for each target manually, and with Go 1.5 it comes by default.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: