[view] ten reasons why I don’t like “ten reasons why I don’t like go language”


Ten reasons why I don’t like go language by Lawrence, June 17, 2019

Ten reasons why I don’t like “ten reasons why I don’t like go language” by WZY_ CC 2020/07/08

Ten reasons why I don’t like go language author Lawrence has been using go language for three years and has participated in many large go projects. But he has now given up on go and thinks it is “intolerable in bad ways.”. But I think some of the reasons are far fetched. View 1-10 is the author’s ten reasons for not liking go language


The go language uses initial case to determine the visibility of identifiers

In fact, it is very smart to use case to distinguish public and private variables and methods exposed outside the package. It not only reduces the number of keywords, but also makes the whole look elegant.

If you change from Java or C + + to go development, you will naturally have problems with the lack of JavapublicandprivateThe author thinks that the initial capitalization should “contain other meanings”. In the go language specification, the package name, function name and variable name should be lowercase. Then the capitalization methods and variables are naturally exposed outside the package to provide access. Constant capitalization is the Convention, and it is still used by the userconstIt’s not a big problem to distinguish keywords

The author believes that the following codes are bad because of lowercase letters:

type user struct {
  name string

func main() {
  var user *user
  user = &user{} // Compile error

In the above code, user is a private structure, and the variable of the structure is user. There is an error in compiling. The user type is treated as a user variable and cannot be compiled. In fact, it’s not a big problem. Any such declaration, which is not distinguished by the name of a variable and has no practical meaning, is a mistake in the code of any languageIt’s terribleYes.

Naming is a habit of developers. If someone in the core development team is used to short naming and attacks the language, is it a bit of putting the cart before the horse.


The struct does not explicitly declare which interfaces it implements, but identifies them by matching method signatures

Go has no class. You are right about everything.


The go language does not have an exception, but returns an error through multiple return values

This is just one of the features of go that distinguishes it from other languages. It requires developers to pay attention to and explicitly deal with possible errors. Moreover, the author mistakenly believes that err can be assigned to ﹣ U, This kind of error handling method is advocated to remind developers, and will not make developers “forget” to check whether the return value contains errors. It is the developers’ own code that is not robust enough, rather than the defects of the language itself.

In the following code, the author thinks that it is not guaranteed that user and err contain correct values, and user may not be assigned a value

user, err := getUserById(userId)

It’s beyond my understanding, and I can’t understand that in other languages, unassigned values can be checked in some way without relying on reflectionValueofAnd so on?


Magical behavior of go code

The author thinks that it happens to define a function name asinit()It will be called automatically at run timeinit()Functions are called before the main function, and undefined errors are reported if called explicitly. RecommendedInit()To initialize objects and links. Peter bourgon thinks it should be reduced as much as possibleinit()Function.


Because of the cap convention, it’s easy to have many of the same identifiers

”Some package names, struct names, and variable names are called items. In Java, the package name uses a fully qualified name, and the first letter of the class name is capitalized. Sometimes it’s hard to read go code, because you may not be able to see the scope of an identifier all at once“

The duplicate name of structure variable name in the same package cannot be passed at compile time. As for the alias of package name and the duplicate name of variable, it belongs to the problem of development habit.


Go code is not easy to compile

Too strict compiler is a good thing for developers. For developers’ code level, the more strict the compiler, the higher the code quality. This is definitely one of the excellent features of go.


Go language has no ternary operator (?:)

There is no ternary operation, and the conversion to complex branch statements, it really becomes not elegant


The sort interface is stupid

Three functions are needed to implement the sort interface by custom type, while 30 functions must be written when there are ten structs. The author thinks that 20 of them are the same. This is because go lacks generics. If there is no template in C + +, sorting is also a disaster.

The author thinks that transformation looks like a function


In fact, there is no problem in understanding it as function passing.


Missing generics

Adding generics is the most popular voice in the community. In fact, go generics will be added in the upcoming version 2.0.


Not from the perspective of programmers

The author gives an example of the append function, where append returns a new array:

users = append(users, newUser)

The author thinks that the following line of code can always be called successfully is the worst

append(users, newUser)

Because the function modifies the original array when possible, and returns a new array if there is not enough space. And this bad design has been modified in the latest compiler, whenappendA function that is not a right value cannot pass at compile time.


Other voices in the Hacker News Community

Packages and variables that are not imported in a project will lead to compilation errors. Forcing the compiler to patch and ignoring errors is essentially a retrogression. Since they are not used, why should they be declared? This is why go is easier to maintain than PHP

If you want to sort a fragment,sort.Slicethansort.Interfacebetter

No confusing interface should be defined in any language


Whether the language is good or bad depends on whether the developer likes it or not, and whether the business needs it or not. Whether to choose a language depends not on its design, but on whether it can solve your problems.

The language developers like is of course a “good” language for developers, and the author may be used to some Java usage methods, and is not used to it because there are few go sugars, so grammar sugar is not a necessity.

About whether it should be used in goinit()Function, see “some theories of modern go”