Go 101 articles mainly focus on syntax and semantics in Go. There are some other Go related topics which are not covered in Go 101. The remaining of the current article will make simple introductions to those topics and provide some web links for readers to dig more into them.
go test command in Go Toolchain to run tests and benchmarks.
Test source file names must end with _test.go.
Go Toolchain also supports profiling Go programs.
Please read the following articles for more details.
gccgo is another Go compiler maintained by the Go core team.
It is mainly used to verify the correctness of the standard Go compiler (gc).
We can use the -compiler=gccgo build option in several Go Toolchain
commands to use the gccgo compiler instead of the gc compiler.
For example, go run -compiler=gccgo main.go.
This option requires the gccgo program is installed.
Once the gccgo program is installed,
we can also use the gccgo command directly to compile Go code.
go/* Standard Packages
The go/* standard packages provide functionalities of
parsing Go source files, which are very useful to write custom Go tools.
Please read go/types: The Go Type Checker
and package documentation for how to use these packages.
We can make system calls by call the functions exported by the
syscall standard package.
Please beware that, different from other standard packages,
the functions in the syscall standard package are operating system dependent.
Go functions can be implemented with Go assembly language. Go assembly language is a cross-architectures (though not 100%) assembly language. Go assembly language is often used to implement some functions which are critical for Go program execution performances.
It is possible to use C++ libraries through cgo by wrapping C++ libraries as C functions.
Please note that using cgo in code may make it is hard to maintain cross-platform compatibility of Go programs, and the calls between Go and C code are some less efficient than Go-Go and C-C calls.
GOOS and GOARCH environments
before running the go build command,
we can build a Windows executable on a Linux machine, and vice versa.
Please read the following articles for details.
The standard Go compiler supports several
compiler directives.
A directive appears as a comment line like //go:DirectiveName args.
For examples, we can use the go:generate directive
to generate code and use the go:embed directive
(introduced in Go 1.16) to embed some data files in code.
We can use build constraints
to let compilers build source files selectively (a.k.a., ignore some source files).
A build constraint is also called a build tag.
A build constraint can appear as a comment line like // +build constraints
or appear as the suffix in the base name of a source file.
Please note: the new //go:build
directive introduced in Go 1.17
will retire the old // +build constraints lines eventually.
The go build command in Go Toolchain supports several build modes.
Please run go help buildmode to show the available build modes
or read the explanations for -buildmode option instead.
Except the default build mode, the most used build mode may be the plugin build mode.
We can use the functions in the plugin standard package
to load and use the Go plugin files outputted by using the plugin build mode.
The Go 101 프로젝트는 Github 에서 호스팅됩니다. 오타, 문법 오류, 부정확한 표현, 설명 결함, 코드 버그, 끊어진 링크와 같은 모든 종류의 실수에 대한 수정 사항을 제출하여 Go 101을 개선을 돕는 것은 언제나 환영합니다.
주기적으로 Go에 대한 깊이 있는 정보를 얻고 싶다면 Go 101의 공식 트위터 계정인 @go100and1을 팔로우하거나 Go 101 슬랙 채널에j가입해주세요.
reflect 표준 패키지sync 표준 패키지sync/atomic 표준 패키지