I feel it is hard to describe the contents in this article in the general description manner. So this article will use the interview manner to make descriptions instead.
At about July 2016, after (not very intensively) using Go for two years, I felt that Go is a simple language and I had mastered Go programming. At that time, I had collected many details in Go programming. I thought I can archive these details into a book. I thought it should be an easy job.
I was wrong. I was overconfident. In trying to make explanations for some details, I found I couldn't explain them clearly. With more and more confusions being gathered, I felt my Go knowledge was so limited that I was still a newbie Go programmer.
I gave up writing that book.
It was that book being cancelled, not the book Go 101. I eventually cleared almost all the confusions by reading many official Go documentation and all kinds of Go articles on Internet, and by finding answers from some Go forums and the Go project issue tracker.
I spent about one year clearing the confusions. During the period, from time to time, once I had cleared most confusions on a topic and regained the confidence on explaining that topic, I wrote one blog article for that topic. In the end, I had written about twenty Go articles. And I had collected more Go details than before. It was the time to restart the plan of writing a Go book.
I wrote another ten basic tutorial articles and twenty more articles on all kinds of other Go topics. So now Go 101 has about 50 articles.
Some of the confusions were a few syntax and semantics design details, some of them involved values of certain kinds of types (mainly slices, interfaces and channels), and a few of them were related to standard package APIs.
Thinking Go is easy to master is considered harmful. Holding such opinion (thinking Go is easy to master) will make you understand Go shallowly and prevent you from mastering Go.
Go is a feature rich language. Its syntax set is surely not large, but we also can't say it is small. Some syntax and semantics designs in Go are straightforward, some are a little counter-intuitive or inconsistent with others. There are several trade-offs in Go syntax and semantics designs. A programmer needs certain Go programming experiences to comprehend the trade-offs.
Go provides several first-citizen non-essential kinds of types. Some encapsulations are made in implementing these types to hide the internal structures of these types. On one hand, the encapsulations bring much convenience to Go programming. On the other hand, the encapsulations make some obstacles to understand the behaviors of values of these types more deeply.
Many official and unofficial Go tutorials are very simple and only cover the general use cases by ignoring many details. This may be good to encourage new Go programmers to learn and use Go. On the other hand, this also makes many Go programmers overconfident on the extent of their Go knowledge.
Several functions and types declared in some standard packages do not have detailed explanations. This is understandable, for many details are so subtle that it is hard to find proper wordings to explain them clearly. Saying a few accurate words is better than saying lots of words with inaccuracies. But this really leaves some confusions for the package users.
I think, at least, simplicity is not a main selling point of Go. After all, there are several other languages simpler than Go. On the other hand, Go, as a feature rich language, is also not a complicated language. A new Go programmer with right attitudes can master Go programming in one year.
Personally, I think the fact that, as a static language, Go is flexible as many dynamic script languages is the main selling point of Go language.
Memory saving, fast program warming-up, fast code execution speed and fast compilations combined is another main selling point of Go. Although this is a common selling point of many C family languages. But for web development area, seldom languages own the four characteristics at the same time. In fact, this is the main reason why I switched to Go from Java for web development.
Built-in concurrent programming support is also a selling point of Go, though personally I don't think it is the main selling point of Go.
Great code readability is another important selling point of Go. I feel readability is the most important factor considered in designing Go.
Great cross-platform support is also a selling point of Go, though this selling point is not much unique nowadays.
A stable core design and development team and an active community together can also be viewed as a selling point of Go.
This book doesn't touch custom generics in depth. Please read the Go Generics 101 book to learn about custom generics.
In addition, type parameter types (used frequently in custom generics) are deliberately ignored in the descriptions of conversion, assignability and comparison rules. In other words, this book doesn't consider the situations in which custom generics are involved.
The Go 101 프로젝트는 Github 에서 호스팅됩니다. 오타, 문법 오류, 부정확한 표현, 설명 결함, 코드 버그, 끊어진 링크와 같은 모든 종류의 실수에 대한 수정 사항을 제출하여 Go 101을 개선을 돕는 것은 언제나 환영합니다.
주기적으로 Go에 대한 깊이 있는 정보를 얻고 싶다면 Go 101의 공식 트위터 계정인 @go100and1을 팔로우하거나 Go 101 슬랙 채널에j가입해주세요.
reflect 표준 패키지sync 표준 패키지sync/atomic 표준 패키지