Although Go intends to make your programming experience better and save you from the quirks of C, C remains a very capable programming language that is still useful. This means that there are situations, such as when using a database or a device driver written in C, that still require the use of C, which means that you will need to work with C code in your Go projects.

The simplest way to call C code from a Go program is to include the C code in your Go source file. This needs special treatment but it is pretty...

It is also possible to call a Go function from your C code. Therefore, this section will present you with a small example where two Go functions are going to be called from a C program. The Go package is going to be converted into a C shared library that is going to be used in the C program.

This subsection will present you with the code of the Go package that will be used in a C program. The name of the Go package needs to be main but its filename can be anything you want; in this case, the filename will be usedByC.go and it will be presented in three parts.

The first part...

The defer keyword postpones the execution of a function until the surrounding function returns, which is widely used in file input and output operations because it saves you from having to remember when to close an opened file. The defer keyword allows you to put the function call that closes an opened file near to the function call that opened it. As you will learn about the use of defer in file-related operations in Chapter 8, Telling a UNIX System What to Do, this section will present two different usages of defer. You will also see defer in action in the section that talks about the panic() and recover() built-in Go functions, as well as in the section that is related to logging.

It is very important to remember that deferred functions are executed in last in, first out (LIFO) order after the return of the surrounding function. Putting it simply, this means...

This section will present you with a tricky technique that was first mentioned in the previous chapter. This technique involves the use of the panic() and recover() functions and will be presented in panicRecover.go, which you will see in three parts.

Strictly speaking, panic() is a built-in Go function that terminates the current flow of a Go program and starts panicking. On the other hand, the recover() function, which is also a built-in Go function, allows you to take back control of a goroutine that just panicked using panic().

The first part of the program is next:

package main 
 
import ( 
    "fmt" 
) 
 
func a() { 
    fmt.Println("Inside a()") 
    defer func() { 
        if c := recover(); c != nil { 
            fmt.Println("Recover inside a()!") 
        } 
    }() 
    fmt.Println("About to call b()") 
    b...

There are times when a UNIX program fails for some unknown reason or does not perform well and you want to find out why without having to rewrite your code and add a plethora of debugging statements.

This section will present two command-line utilities that allow you to see the C system calls executed by an executable file. The names of the two tools are strace(1) and dtrace(1) and they allow you to inspect the operation of a program.

Although both tools can work with the go run command, you will get less unrelated output if you first create an executable file using go build and use this file. This mainly occurs because, as you already know, go run makes various temporary files...

This section will talk about finding out information about your current Go environment using the functions and the properties of the runtime package. The name of the program that will be developed in this section is goEnv.go and it will be presented in two parts.

The first part of goEnv.go is next:

package main 
 
import ( 
    "fmt" 
    "runtime" 
) 

As you will see in a while, the runtime package contains functions and properties that will reveal the desired information. The second code portion of goEnv.go contains the implementation of the main() function:

func main() { 
    fmt.Print("You are using ", runtime.Compiler, " ") 
    fmt.Println("on a", runtime.GOARCH, "machine") 
    fmt.Println("Using Go version", runtime.Version()) 
    fmt.Println("Number of CPUs:", runtime.NumCPU...

If you need to get a list of all environment variables supported by Go and the Go compiler, along with their current values, then the solution is to execute go env.

On my macOS Mojave, which uses Go version 1.11.4, the pretty rich output of go env is as follows:

$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/mtsouk/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/mtsouk/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/Cellar/go/1.11.4/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.11.4/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2&quot...

This section will briefly talk about the assembly language and the Go assembler, which is a Go tool that allows you to see the assembly language used by the Go compiler.

As an example, you can see the assembly language of the goEnv.go program you saw in the previous section of this chapter by executing the next command:

$ GOOS=darwin GOARCH=amd64 go tool compile -S goEnv.go
  

The value of the GOOS variable defines the name of the target operating system whereas the value of the GOARCH variable defines the compilation architecture. The preceding command was executed on a macOS Mojave machine, hence the use of the darwin value for the GOOS variable.

The output of the previous command is pretty large even for a small program such as goEnv.go. Some of its output is next:

"".main STEXT size=859 args=0x0 locals=0x118
   0x0000 00000 (goEnv.go:8)       TEXT...

A Go node is a struct with a large number of properties. You will learn more about defining and using Go structures in Chapter 4, The Uses of Composite Types. Everything in a Go program is parsed and analyzed by the modules of the Go compiler according to the grammar of the Go programming language. The final product of this analysis is a tree that is specific to the provided Go code and represents the program in a different way that is suited to the compiler rather than to the developer.

This section will first use the following Go code, which is saved as nodeTree.go, as an example in order to see the kind of low-level information the go tool can provide us with:

package main 
 
import ( 
    "fmt" 
) 
 
func main() { 
    fmt.Println...

If you want to learn more about what is happening behind the scenes when you execute a go build command, you should add the -x flag to it:

$ go build -x defer.go
WORK=/var/folders/sk/ltk8cnw50lzdtr2hxcj5sv2m0000gn/T/go-build254573394
mkdir -p $WORK/b001/
cat >$WORK/b001/importcfg.link << 'EOF' # internal
packagefile command-line-arguments=/Users/mtsouk/Library/Caches/go-build/9d/9d6ca8651e083f3662adf82bb90a00837fc76f55839e65c7107bb55fcab92458-d
packagefile fmt=/usr/local/Cellar/go/1.11.4/libexec/pkg/darwin_amd64/fmt.a
packagefile runtime=/usr/local/Cellar/go/1.11.4/libexec/pkg/darwin_amd64/runtime.a
packagefile errors=/usr/local/Cellar/go/1.11.4/libexec/pkg/darwin_amd64/errors.a
packagefile io=/usr/local/Cellar/go/1.11.4/libexec/pkg/darwin_amd64/io.a
packagefile math=/usr/local/Cellar/go/1.11.4/libexec/pkg/darwin_amd64/math.a
packagefile...

Go allows you to create WebAssembly code with the help of the go tool. Before I illustrate the process, I will share more information about WebAssembly.

WebAssembly (Wasm) is a machine model and executable format targeting a virtual machine. It is designed for efficiency, both in speed and file size. This means that you can use a WebAssembly binary on any platform you want without a single change.

WebAssembly comes in two formats: plain text format and binary format. Plain text format WebAssembly files have the .wat extension, whereas binary files have the .wasm file extension. Notice that once you have a WebAssembly binary file, you will have to load and use it using the...

The following is a list of practical advice that will help you to write better Go code:

• If you have an error in a Go function, either log it or return it; do not do both unless you have a really good reason for doing so.
• Go interfaces define behaviors not data and data structures.
• Use the io.Reader and io.Writer interfaces when possible because they make your code more extensible.
• Make sure that you pass a pointer to a variable to a function only when needed. The rest of the time, just pass the value of the variable.
• Error variables are not string variables; they are error variables!
• Do not test your Go code on production machines unless you have a really good reason to do so.
• If you do not really know a Go feature, test it before using it for the first time, especially if you are developing an application or a utility that will be used by a large number...

• Learn more about the unsafe standard Go package by visiting its documentation page at https://golang.org/pkg/unsafe/.
• Visit the web site of DTrace at http://dtrace.org/.
• Use strace(1) on your Linux machine to inspect the operation of some standard UNIX utilities such as cp(1) and ls(1). What do you see?
• If you are using a macOS machine, use dtruss(1) to see how the sync(8) utility works.
• Write your own example where you use your own C code from a Go program.
• Write a Go function and use it in a C program.
• You can find more information about the functions of the runtime package by visiting https://golang.org/pkg/runtime/.
• Reading research papers might be difficult but it is very rewarding. Please download the On-the-Fly Garbage Collection: An Exercise in Cooperation paper and read it. The paper can be found in many places, including https://dl.acm.org/citation...

This chapter discussed many interesting Go topics, including theoretical and practical information about the Go garbage collector; how to call C code from your Go programs; the handy and sometimes tricky defer keyword; the panic() and recover() functions; the strace(1), dtrace(1), and dtruss(1) UNIX tools; the use of the unsafe standard Go package; how to generate WebAssembly code from Go; and assembly code generated by Go. Finally, it shared information about your Go environment using the runtime package and showed how to reveal and explain the node tree of a Go program, before giving you some handy Go coding advice.

What you should remember from this chapter is that tools such as the unsafe Go package and the ability to call C code from Go are usually used on three occasions: firstly, when you want the best performance and you want to sacrifice some Go safety for it;...