
Go Will Dominate the Next Decade - bsg75
https://www.linkedin.com/pulse/go-dominate-next-decade-ian-eyberg
======
timmytokyo
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.

------
matthewmacleod
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.

------
CmonDev
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...](http://www.ivystreetstudio.com/wp-
content/uploads/2010/04/discostustats.jpg)

------
Samis2001
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.

------
ilurkedhere
> 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.

------
bphogan
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?

~~~
sagichmal
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](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.

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

~~~
sagichmal
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.

