Why do I give up the go language

This is a creation in Article, where the information may have evolved or changed.

Several times, when I think about it, I always ask myself: why should I give up the go language? Is this the right decision? Is it sensible and rational? In fact, I have been seriously thinking about this problem.

To be straight to the point, I gave up the go language because of the two "bad": first, the go language itself is uncomfortable, second, to the go language community of some people unhappy. There is no doubt that this is a very subjective conclusion. But I have an objective argument that is sufficiently detailed to support this seemingly subjective conclusion.

Section No. 0: My go language experience

Let me tell you about my experience to avoid being the low-level black of the go language for no reason.

At the end of 2009, the first release of the go language, shrouded in the "Google made" Halo, attracted a lot of early adopters, I (Liigo) also live in it, a general look at some of the Go language materials, learning the basic tutorial, because of its grammatical semicolon and braces dissatisfaction, Soon forgotten, did not take it as the same thing.

Two years later, at the end of 2011, the Go Language Release 1.0 program was put on the agenda, and the related reports came up again, and I followed it again, [re-evaluated][1] and decided to take a deep dive into the go language. I subscribed to the official e-mail groups of users, nuts, Dev, commits, and insisted on reading the email every day, as well as every source code update submitted by the developer, and submitted many improvements to go, even including [modifying the go language compiler source code][2] to participate directly in the development task. It lasted a few months.

By the beginning of 2012, the Go 1.0 release, the language and standard library have been basic stereotypes, there is no possible significant improvement, I am not in the go language before the 1.0 to a step forward, to achieve self-breakthrough, even with a lot of obvious flaws to 1.0, feel very disappointed, so gradually alienated it (so Go I seldom care about the things after 1.0). Later, I saw the release Note of Go 1.1 that was about to be released, and found that the language level had not changed much, but that it had been patched and improved at the library and tools level, and felt that it had lost its momentum of growth at a young age and was increasingly disappointed. And some of the people in the go language community, including some of Google's people who are responsible for developing the go language, have been extremely disgusted with their attitude, words and deeds, prompting me to abandon the go language.

1:https://plus.google.com/+liigozhuang/posts/cprnpedxudw

2:http://blog.csdn.net/liigo/article/details/7467309

1th: Why am I upset with the go language?

There are a lot of things that make me uncomfortable with the go language, and here is a list of some of the places I can remember now, which are basically in no particular order. After reading patiently, can the reader calmly say "I don't care"?

1.1 Do not allow left curly braces to start another line

About the placement of curly braces, in C, C + +, Java, C # and other communities, more than 10 years of continuous controversy, has never formed a consensus. In my opinion, this is the subjective tendency very heavy choice, does not violate the principle does not involve the right and wrong situation, should not engage in the fits, lets the programmer or the team own choice is enough. The programming language itself imposes restrictions, and it is not worth the candle to impose its own preferences on others. Whatever tends to be one of them, it is inevitable to offend a group of people against them. Although I am used to putting the left curly braces at the end of the line, I feel very uncomfortable when I think of being banned from other options. Go language This issue, did not do "unite all can unite the power" does not say, also intentionally gives oneself the enemy, too failed.

1.2 The compiler inexplicably adds a semicolon to the end of the line

For the go language itself, the semicolon at the end of the line can be omitted. However, in its compiler (GC) implementation, in order to facilitate the compiler developers, but in the lexical analysis phase forcibly added a line end of the semicolon, which in turn affects the language specification, "How to add a semicolon" to make special provisions. This kind of metamorphosis is unprecedented. In the case where the left curly brace is accidentally placed at the beginning of the next line, it automatically adds a semicolon at the end of the previous line, causing an inexplicable compilation error (before Go 1.0), even if it doesn't understand itself. If you do not handle the semicolon, simply do not omit the semicolon, or, Scala and JavaScript compiler is open source, and they learn how to deal with the omit line end semicolon can it?

1.3 Extreme emphasis on the speed of compilation, regardless of the function should be provided

The programmer is a person is not God, the coding process inevitably because of the carelessness or neglect to make some mistakes. Some of them, is the collective nature of the very easy to take the wrong (the Go language example I can not remember, C + + examples are "base class destructor is not virtual function"). At this time the compiler should stand out, do more checks, constraints, check the work, try to prevent the occurrence of regular errors, try not to let the potential error code compiled through, if necessary, give some warnings or hints, let the programmer pay attention to. compiler is not a machine, is not to do more dirty work dirty miscellaneous work, reduce the mental burden of people? The compiler does a lot of checking, it may avoid hundreds of thousands of of programmers in the next many years to make the same mistake countless times, save countless times, this is boundless beneficence good. But the authors of the go compiler don't think so, and they don't want to spend more hours adding new features to the compiler, feeling that it's a loss, but slowing down the compilation speed. They rejected a lot of requirements for compiler improvements by affecting compilation speed. A typical unworthy. The emphasis on compiling speed is commendable, but I don't approve of it if I give up the proper functionality.