I’ve decided recently to get serious about learning golang. I’ve had a great time playing around with other peoples code (Docker and Kubernetes namely) and it’s time for me to learn the language so I can contribute more than bash scripts. For better of for worse, I’ve decided to start coding on a CentOS box. I have a couple of reasons for doing this…
-Its the Linux distro I’m most familiar with currently
-I need to get better at working in Linux. More stick time on straight CLI can’t hurt. I feel like jumping into a full blown IDE might be a bit premature for me and possibly allow me to miss some of the basics as well.
-I plan to run the code on Linux servers (I think…?)
Disclaimer: Im just getting started in golang. If something I suggest below is wrong, please tell me! Still learning here
Note: I really struggle with the language being called ‘go’. So Im trying to call it golang everywhere I can. It can seem like a bit much at times…
So let’s get started. The goal of this post is to end up with a functioning development workstation that I can use for playing around with golang. First things first, let’s install some of the tools we’ll need…
#Install golang, git, and vim yum -y install golang git vim
Now that golang is installed (that was easy right?) let’s do one of the most complicated pieces of the configuration, configuring the paths. Regardless, the main goal here is to set the ‘GOPATH’ environmental variable. Let’s first look and see what environment variables golang knows about currently…
So it doesn’t currently have a path for ‘GOPATH’. Before I set one, let’s explain why this is needed. Let’s take the classic ‘Hello World’ go coding example to use. The code for that looks something like this…
package main
import "fmt"
func main() {
fmt.Println("hello world")
}
Let’s put that in a file just called ‘hello.go’ and then try running the code…
Nice! It worked. So as you can see, the ‘run’ command tells the compiler to run the golang file you specify. Now let’s try to build the file…
Above we built a binary file, and then ran it. At this point, that’s a totally independent executable that’s not relying on having golang installed to run it. Pretty slick huh? So since things seem to be working, why do we need to change any paths? We wont be able to cover all the details in this post, but suffice to say that ‘build’ and ‘run’ aren’t how you’ll always be compiling code in golang. Golang uses something called ‘workspaces’ that boil down to a defined directory structure. When building code in workspaces, golang needs a path to tell it where to look. This is what we define as the ‘GOPATH’. So let’s define that, and then talk a little bit about workspaces.
To define the path, I’ll edit my .bashrc file and add the following line…
export GOPATH=$HOME/go
So my .bashrc file now looks like this…
If we source the file, and then check our environmental variables we should see our defined ‘GOPATH”’…
Cool. So now let’s talk about the golang workspace. For now, let’s use this basic structure to define a workspace…
$GOPATH/
bin/ #where installed binaries go
pkg/ #installed packages
src/ #your code repositories
So let’s make the following directories…
mkdir ~/go mkdir ~/go/bin mkdir ~/go/pkg mkdir ~/go/src
To give you an idea of how the file structure is important, let’s move our hello world application into the workspace. To do this, I’ll create a folder for it under the /src directory, move the ‘hello.go’ file into it, and then run a ‘go install’…
Ok – so what happened? Go built an executable for us and put it in the bin directory for us…
It knew how to do this based on the ‘GOPATH’ environmental variable. If this wouldn’t have been defined as we did above, we would have received an error like this…
Ok – So that’s about as far as I want to go with the golang stuff tonight, however, there is one other component I want to cover. While I decided not to use a IDE, I can still get some pretty decent syntax tools for golang using VIM. For instance, let’s take a look at what I get right now with the base VIM install…
Just sort of the basics right? VIM can tell me where the opening and closing brackets/braces are but that’s about it. So Im going to install a VIM plugin called ‘vim-go’. To install the plugin, I’m going to use a VIM plugin manager called ‘Vundle’.
#Pull down Vundle git clone https://github.com/gmarik/Vundle.vim.git ~/.vim/bundle/Vundle.vim #Edit your .vimrc file and insert this config set nocompatible filetype off set rtp+=~/.vim/bundle/Vundle.vim call vundle#rc() Plugin 'gmarik/Vundle.vim' Plugin 'fatih/vim-go' filetype plugin indent on
At this point, we’ve installed Vundle and we’ve told it to install the vim-go plugin. Let’s load VIM now and tell it to install the plugins. We do this by start VIM and using the VIM command ‘:PluginInstall’…
Now use the command ‘:bdelete’ to exit Vundle and go back to the main screen. That’s it, the vim-go plugin is installed. Let’s go back and checkout our hello.go file now…
Save the highlighting, it doesn’t look too different does it? Let’s write the file (:wq) and then open it again…
Nice! The plugin automatically reformats the code when we write the file. We also get some other cool built in functions but I’ll cover those in greater detail in future posts.
Lastly, I also found this pretty awesome color scheme called molokai for VIM that I find makes coding easier. Install is pretty easy…
#Pull down the color scheme wget https://raw.githubusercontent.com/fatih/molokai/master/colors/molokai.vim -O ~/.vim/colors/molokai.vim #Edit your .vimrc file and insert this config colorscheme molokai
So we’re up and running now, next step is to start writing some code and get it out on GitHub. Hopefully more coming soon!
Great article, Jon! Especially enjoyed the part about setting up Vim, have to dig into that soon… (seeing it’s basically on every *nix box these days…) I myself have installed and am using GitHub’s Atom editor (https://atom.io/) which as great Go support with the “go-plus” plugin installed (this is on Ubuntu Linux btw.) A few comments based on what I read in your article, that may help others just starting out with Linux/Golang:
– Linux versions don’t really matter (much) if you just are working in “userland” — in this area, Linux distros are basically all alike. It’s when you get into system administration (setup) that all the differences rear their head (as I’m sure you know!) The biggest difference for “regular” users (dev’s) would probably be package managers (RHEL/CentOS/Fedora = ‘yum’, Debian/Ubuntu/Mint = ‘apt-get’ or ‘aptitude’ [a shell around apt-get…]) I find that the latest Ubuntu makes a great dev workstation/laptop OS, but YMMV.
– I’ve been reading the suggested articles/books “How To Write Go” and “Effective Go” [1], and it suggests the following concerning setting up the directory path for the Go workspace(s): “If you keep your code in a source repository somewhere, then you should use the root of that source repository as your base path.” So, under ‘src’, set up a directory structure that mirrors the path of your primary source repository URL (such as in my case, ‘src/github.com/wdennis/mygoproject’) and put your Go sources there for the project at hand. This is useful for keeping import namespaces non-conflicting, and also per How to Write Go, “using this convention, the go command can automatically check out and build the source code by its import path alone” (haven’t tried this myself yet…)
– setting the environmental variables GOPATH and adding the $GOPATH/bin folder to your $PATH (so that you can just type your Go program names at any command prompt, and the system with find them) is typically done in .profile, not .bashrc – not sure it operationally matters, but just the standard convention. I have the following at the bottom of my .profile :
Hi Will – Thanks for the comments! A couple quick responses to your comments…
-The file structure you reference makes total sense and I could see how the tie in with the ‘go’ commands would be helpful. I’ll give that a try.
-I put the GOPATH in my bashrc file since I thought bashrc was used for interactive and noninteractive mode. I thought that bash_profile was used for only interactive mode and I thought since I dont yet fully know what Im doing that the ‘both’ option would cover all my bases 🙂
It sounds like you’re on Ubunutu. Are you running on a text only CLI or using the GUI? I’d certainly like to try Atom if it’s available in text only CLI mode. Im trying to stay there for now rather than use any GUIs.
Thanks again!
Hi Jon,
My bash initialization notes state:
~/.bash_profile (or ~/.bash_login or ~/.profile) is the user-specific bash init file (if not found, will try to source .bash_login and if that’s not found, will try to source .profile, but only the first one found will be sourced)
– only sourced when bash is called by login
– used for user-specific startup things
~./bashrc is sourced every time a new or interactive bash shell is started by the user, or when they run a bash script.
– used for user’s functions, aliases, etc.
– bash shell options usually set here
So, it makes sense to put env stuff in the login script, as you only should have to do that once at the start of a login session, and not every time you spawn a new shell… But it won’t hurt anything to do it in both places I guess 🙂
No, Atom is a GUI editor – I myself use vim (not quite a power user yet 😉 at the CLI.
– Will
I’m surprised the version of golang in the Centos 7 repo was new enough for you.
I’m getting back into python, and annoyingly centos 7 is still running on python2, so I am looking at moving to Fedora 22 (server edition) for my dev servers. It has python2 and python3 installed side by side, and the packages are about as bleeding edge as you want to get.
Btw– if you are still running proxmox you should check out the proxmox 4.0 beta. It’s running on a 3.19 kernel currently, which a nice step up from the 2.6 kernel that they are using in v.3.4. I’ve been using it to test some 10Gb networking and some other stuff, and it has been stable so far.
Its new enough for me because I dont think I know what Im doing yet 🙂
I am still on proxmox but in the 3.x train. Im just happy to have HTML VNC at this point 🙂
Hey, I heard pedants were welcome here! Nice piece Jon.
I concur with Will that ~/.bash_profile is the correct place for USER path modifications.
My understanding (where CentOS is concerned anyway) and based on the notes in the /etc/profile file, is that any required GLOBAL path modifications should go in a file here: /etc/profile.d/some_name.sh.
You can also save your self a few keystrokes by using this instead of the ‘printenv’ command: ‘env |grep GO’
On a more helpful note, I just yesterday discovered vim’s diff function which allows you to use vim to compare two (or more files) like so: ‘vi -d filename1 filename2
Hi Steven,
Thanks for the feedback and the tips! I’m going to give the bath profile a go tonight and see if it works as expected on my end.
Thanks for reading! – Jon