Linux distributions and other Unixes often package versions of languages for you. This has good bits, such as easy installation and someone else worrying about the packaging, and bad bits, such as the versions potentially being out of date. For many languages (C being a great example), the exact version doesn't matter too much, and most any version installed by a Linux distribution will be fine for most people. Unfortunately Go's current strong transition to modules makes it not one of those languages; you now need a version of Go with (good) module support. Which leads to this tweet of mine:

It makes me a bit sad that Ubuntu 18.04's packaged version of Go is 1.10, which is one version too old to have any modules support. It's very Ubuntu but I still wish they'd updated since release.

On operating systems with versions of Go that are too old, such as Ubuntu 18.04, you should get or build your own local copy of a good version of Go, which probably should be the latest version. Fortunately this is an easy process; unfortunately it will complicate simply working with programs that written in Go and that you need to build yourself (possibly including locally written programs). Even if you can sort of work with the system version of Go when it lacks module support, I don't think you should try to do so; it's not going to be worth the extra pain and work.

(Related to this, you might want to start installing third party Go programs with 'go install ...@latest' or 'go get ...@latest', since both of these force modular mode if they work at all.)

There are at least three reasons to use a version of Go that supports Go modules and to use Go modules yourself. First, it's the way that the ecosystem is moving in general. I expect that an increasing number of development tools and general programs that work with Go code are going to require and assume modules, or at least work much better with modules. Like it or not, traditional $GOPATH Go development is going away as people drop code for it or the old code quietly stops working.

Second, Go modules are the mostly the better way to develop your own local programs. They complicate your life if you have your own local packages that you don't want to publish somewhere, but if you don't use local, un-published packages then they're a great way to get self-contained Go program source. And of course modules make it far less likely that random changes in outside packages that you use will break your programs.

Third, it's likely that a steadily increasing number of third party programs will stop building without modules, because they're set up to use older versions of third party packages (or older versions of their own packages). You could generally build them by hand with a carefully constructed $GOPATH environment, but using a version of Go with module support is much easier.