Create the first Go language program Hello,go!_golang

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

First, create a file under the Go-examples hello.go

Copy Code code as follows:

Hello.go
Package Main

Import "FMT"//implementation of formatted I/O

/*printf someting*/
Func Main () {
Fmt. Printf ("hello,go!\n")
}

Let's Analyze This program:

1, the 2nd line of the program this is necessary. All go files start with package <something>, and must be package main for standalone run execution files;

2, line 4th says you need to add the "FMT" package to main. Other packages that are not main are called libraries, and many other programming languages have similar concepts.

3, line 1th and line 4th//and/*---

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

5, line 8th calls the function from the FMT package to print the string to the screen

Second, compile and run code

Compiling the source file and executing the generated executable file

Copy Code code as follows:

[Root@localhost go-examples]# Go Build hello.go
[Root@localhost go-examples]# ls
Hello Hello.go
[Root@localhost go-examples]#./hello
Hello,go!

By going to build with the Go source file name, we can get an executable file, by default, the name of the file is the source file name removed. go suffix. Of course, we can also specify other names by using the-o option:

Copy Code code as follows:

[Root@localhost go-examples]# go build-o firstgo hello.go
[Root@localhost go-examples]# ls
Firstgo Hello.go

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

Copy Code code as follows:

[Root@localhost go-examples]# Go Build
[Root@localhost go-examples]# ls
Go-examples Hello.go

Iii. Program Entry points (entry point) and packages (package)

Go maintains the same style as the C-family language: It is important to have a function named Main in the went source for the executable program, which is the entry point for the executable. Besides, go also adds a constraint: The main function as the entry point must be in the package named Main. As in the Hellogo.go source file above, the first line of the source code declares that the file belongs to package as main.

Go removes the concept of the header file, and draws on the package source organization approach used by many mainstream languages. Package is a logical concept and has no one by one correspondence with the file. If multiple source files declare that they belong to a package named Foo at the beginning, the code in these source files logically belongs to package foo (these files are best in the same directory, and at least the current go version does not support the same package for source files in different directories).

We see import a package named FMT in Hellogo.go and use the printf function inside the package to output "Hello, go!". Intuition tells us that the FMT package appears to be a package in a standard library. Yes, the FMT package provides a format for text output and a correlation function to read formatted input, similar to printf or scanf in C. After importing the FMT package into our source file through the import statement, we can use the FMT package export function (for example, Printf).

In C, we identify local or global functions by static. In go, whether a function in a package can be called externally depends on whether the first parent of the function name is uppercase. This is a Go language curing convention: The first-parent capitalization function is considered to be an exported function that can be called by code outside the package, whereas a function that starts with a lowercase letter can only be used in a package. In the example you also see the FMT package's printf function whose first parent is capitalized.

Four, Gopath

The above hellogo.go slightly modified, split into two files: Main.go and Hello.go

Copy Code code as follows:

Hello.go
Package Hello

Import "FMT"

Func Hello (who string) {
Fmt. Printf ("hello,%s!\n", WHO)
}

Copy Code code as follows:

Main.go
Package Main

Import "Hello"

Func Main () {
Hello. Hello ("Go")
}

Compiling main.go with Go build results as follows

Copy Code code as follows:

[Root@localhost go-examples]# Go Build main.go
Main.go:4:8:import "Hello": Cannot find Package

The compiler could not find Hello this package, and hello.go clearly defined package hello. What the hell is going on here? The original Go compiler search package is different from our usual understanding, go has a set of conventions in this respect, which involves an important environment variable: Gopath. We can use Go help Gopath to see the manual about Gopath.

The package search order for Go compiler is such as to search the Hello Package for example:

* First of all, go compiler will find out if there is a Src/pkg/hello-related packet source under Goroot, this is/home/go/, and if not, continue;

* If Export gopath=path1:paht2, then go compiler to find if there is Path1/src/hello, Path2/src/hello PATH1 and PATH2, which are configured in Gopath, are called workplace;

* If you cannot find hello this package in several of these locations, you are prompted for an error.

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 can't find the Hello package. Let's set up the Gopath variable and create the relevant directory:

Copy Code code as follows:

[Root@localhost go-examples]# Export gopath=/home/go-examples/
[Root@localhost go-examples]# mkdir src/hello-p
[Root@localhost go-examples]# MV Hello.go src/hello/
[Root@localhost go-examples]# Go Build main.go
[Root@localhost go-examples]# ls
Main Main.go SRC
[Root@localhost go-examples]#./main
Hello,go!

V. Go install

Move Main.go to Src/main, so this demo project seems more reasonable, all the source code is under SRC:

Copy Code code as follows:

[Root@localhost go-examples]# CD src/
[Root@localhost src]# ls
Hello Main.go

Go provides the install command, which, in contrast to the build command, installs the executable file or library file into the agreed directory after the source code is compiled. \ install Let's take the main catalog for example:

Copy Code code as follows:

[Root@localhost src]# CD main/
[Root@localhost main]# Go Install

After the install command was executed, we found that there was no change in the main directory, and the main executable file that was generated at the time of the build was also missing. Don't worry, go install has its own set of conventions:

* Go install (under Src/dir) the compiled executable file is named after its directory name (DIR)

* Go install installs the executable file to the bin directory with the SRC sibling, and the bin directory is automatically created by going install

* Go install the various package that are dependent on the executable file and put it in pkg directory with SRC peers

Now let's look at the bin directory:

Copy Code code as follows:

[Root@localhost go-examples]# ls
Bin Pkg src
[Root@localhost go-examples]# ls bin/
Main

A bin directory does appear, and the program you just compiled is under bin.

Hello.go is not an executable program after compiling, and as main relies on Hello package, Hello is also associated with compilation. This is the same as the result of performing install separately in the Hello directory, and let's try:

Copy Code code as follows:

[Root@localhost src]# CD hello/
[Root@localhost hello]# Go Install
[Root@localhost hello]# ls/home/go-examples/
Bin Pkg src

In our workspace (go-examples directory) There is a pkg directory, pkg directory is a subdirectory named Linux_386, under which there is a file: Hello.a. This is the result of our install. The Hello.go is compiled into HELLO.A and installed into the pkg/linux_386 directory.

The suffix name reminds us of the static shared library, but here's. A is a go-only file format that is incompatible with the traditional static shared library. But the Go language designer uses this suffix name to seem to hope that this. A file also assumes the role of the "Static shared library" in the Go language. We might as well try to see if this hello.a can be treated as a "static shared library" by Go compiler. We remove the Hello directory in src and execute the go build in the main directory:

Copy Code code as follows:

[Root@localhost main]# Go Build
Main.go:4:8:import "Hello": Cannot find Package

The GO compiler hint could not find the Hello package, so the current version of the go compiler seems to ignore the pkg. a file. http://code.google.com/p/go/issues/detail?id=2775 This issue also confirms this, but subsequent go versions are likely to support the link. a file. After all, when we use the third party package, we may not get the source code, and in each project to save a third party package source code is also very detrimental to the project source code later maintenance.