GO

GO

I am also learning GO after being happy with ruby for a long time. The package system is intriguing to me and it forms a central feature that makes GO easier to work in than C, for instance. When writing GO code, one benefits from adopting the GO workspace file structure--set $GOPATH to the directory you want to keep your GO code in (perhaps ~/Dropbox/go or ~/Google Drive/go), within the $GOPATH place a src directory, which will contain all the packages you create. Within src, you place a separate directory for each package you write. A package is the composed of all of the files in this directory. The directory name and the package files inside do not have to match each other--but you will find it most sensible to make them the match (i.e. package strings lives in the src/strings directory). All of the files in a directory should be part of the same package. You don't mix 'package main' file with 'package foo' files. If you mix files in this way, GO will complain when you try to go install the file. The import statement, creates accessibility to exported (capitalized) functions and constants. The accessibility is file-limited. For instance, if you have a file bar.go and you 'import strings' into that file, strings.Replace (as an example) is now available within that file, but not from the rest of the package to which bar.go belongs. From elsewhere in the package (from some separate file), the strings functions won't be visible. If you look at the files composing the standard package strings, you find that  it is composed of:

/usr/local/go/src/pkg/strings
├── reader.go
├── replace.go
├── search.go
├── strings.go

and some test files that we will ignore. reader.go imports [errors, io, and unicode/utf8]; replace imports [io]; search.go does not import anything, and strings.go imports [unicode, unicode/utf8]. You now see why different files of this package must import the same external package. 

That brings us to the realization that GO must keep some sort of registry of the visible code for associated with each file. When looking at a file, it is easy to track down where functions are coming from--'import strings' gives access to strings.Functions. If you don't understand what strings. Somethings does, you can easily 'go doc strings' to find out. All along the way, GO seems to be designed to save you time in the short run--through great tools, and in the long run--by encouraging the developer to adopt well thought-out approaches to organization and design. 

Looking in the source code is very educational. To aid that, I added the following function to my .zshrc file:

function letsGO()
{
  #uses the go directory to find the standard go package and opens the package files in sublime text 2
  #usage: 
  #% letsGO 'package unicode$'

  grep -rl "${1}"  /usr/local/go/src/pkg | xargs subl
}

Happy GO-ing!