Create the first Go language program Hello, Go!

Create a working directory for writing Go programs go-examples, with the absolute path of /home/go-examples. Start writing our first Go program.

1. Create a file under go-examples

Let's analyze this program:

1. This is necessary on line 2 in the program. All Go files start with package <something>, and must be package main for independent execution files;

2. Line 4 says that the "fmt" package needs to be added to main. Other packages that are not main are called libraries, and many other programming languages ​​have similar concepts.

3. // and /*--*/ in line 1 and 4 are comments

4. package main must appear first, followed by import. In Go, package always comes first, then import, then everything else. When a Go program is executed, the first function called is (), which is inherited from C. This function is defined here;

5. Line 8 calls a function from the fmt package to print the string to the screen

2. Compile and run the code

Compile the source file and execute the generated executable file

By adding the Go source file name to compile, we can get an executable file. By default, the name of this file is the source file name without the .go suffix. Of course, we can also specify other names through the -o option:

If we execute the go build command directly in the go-examples directory without the file name afterwards, we will get an executable file with the same name as the directory name:

3. Program entry point (entry point) and package (package)

Go maintains a style consistent with the C family language: that is, in the Go source code with the target executable program, it is necessary to have a function called main, which is the entry point of the executable program. In addition, Go also adds a constraint: the main function as the entry point must be in a package named main. As in the source file above, the package to which the file belongs is declared on the first line of the source code is main.

Go removes the concept of header files and draws on the source code organization method of packages adopted by many mainstream languages. package is a logical concept and has no one-to-one correspondence with files. If multiple source files declare at the beginning that they belong to a package named foo, the code in these source files logically belongs to the package foo (these files are best in the same directory. At least the current Go version cannot support source files in different directories belonging to the same package).

We see that we import a package named fmt and use the Printf function in the package to output "Hello, Go!". Intuition tells us that the fmt package seems to be a package in a standard library. Yes, the fmt package provides related functions for formatting text output and reading formatted input, similar to printf or scanf in C. After we import the fmt package into our source file through the import statement, we can use the fmt package to export the function function (such as Printf).

In C, we use static to identify local or global functions. In Go, whether the function in the package can be called externally depends on whether the first and first and first parents of the function name are capitalized. This is a Go language solidification convention: functions with the first and first and second capital are considered to be exported functions and can be called by code outside the package; functions with lowercase letters can only be used in the package. In the example, you also see that the Printf function of the fmt package has its first and first and second capital.

4. GOPATH

Revise the above slightly and split it into two files: and

Compile with go build. The result is as follows

The compiler actually prompted that the package hello cannot be found, and the package hello is clearly defined. What's going on? It turns out that the way go compiler searches package is different from what we usually understand. Go also has a set of conventions in this regard, which involves an important environment variable: GOPATH. We can use go help gopath to check the manual about gopath.

The search order of Go compiler's package is as follows. Take the search for hello package as an example:

* First, Go compiler will search for whether there is src/pkg/hello related package source code in the GO installation directory (GOROOT, here is /home/go/); if not, continue;

* If export GOPATH=PATH1:PAHT2, the Go compiler will search for whether PATH1/src/hello, PATH2/src/hello exists in sequence; PATH1 and PATH2 configured in GOPATH are called workplaces;

* If the package hello cannot be found in the above locations, an error will be reported.

In this example, we have not set the GOPATH environment variable, nor have we established a path like PATH1/src/hello, so Go compiler obviously cannot find the package hello. Let's set up the GOPATH variable and create the relevant directory:

5. Go install

It will be moved to src/main, so that this demo project looks more reasonable, and all source codes are under src:

Go provides the install command. Compared with the build command, the install command will install the executable file or library file into the agreed directory after compiling the source code. Let's take the main directory as an example:

After the install command was executed, we found that there was no change in the main directory, and the main executable file generated when the original build was gone. Don't worry, Go install also has its own agreement:

* The executable file compiled from go install (under src/DIR) is named after its directory name (DIR)

* go install installs the executable file to the bin directory of the same level as src. The bin directory is automatically created by go install

* go install compiles various packages that the executable file depends on and puts them in the pkg directory of the same level as src.

Now let's take a look at the bin directory:

There is indeed a bin directory, and the program that has just been compiled is under bin.

After compilation, it is not an executable program. While compiling main, since main depends on hello package, hello is also associated and compiled. This is the same as the result of executing install in the hello directory alone. Let's try:

A pkg directory appears under our workspace (go-examples directory). Under the pkg directory is a subdirectory called linux_386, and there is a file below it:. This is the result of our install. It was compiled and installed in the pkg/linux_386 directory.

The suffix name of .a reminds us of static shared libraries, but here .a is a unique file format of Go and is not compatible with traditional static shared libraries. But the designers of Go use this suffix name as if they hope that this .a file will also assume the role of "static shared library" in Go. Let's try it out and see if this can be treated by Go compiler as a "static shared library". We remove the hello directory in src and execute go build under the main directory:

The Go compiler prompts that hello cannot be found, which shows that the current version of Go compiler seems to ignore the .a file under pkg./p/go/issues/detail?id=2775This issue also confirms this, but subsequent Go versions are likely to support linking.a files. After all, when we use third-party packages, we may not be able to obtain its source code, and saving a third-party package source code in each project is also very unfavorable to the later maintenance of the project source code.