Why I won't abandon Python to Go language

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

Author of this article: Russ Cox

Russ Cox, a graduate of MIT and Harvard University, has been involved in the development of Plan 9 and UNIX operating systems at Bell Labs, and recently developed the Go language in Google.

There's a lot of talk about the go language this month, which is just the 3 anniversary of the birth of Go language. The language, driven by Google Giants, is likely to become the mainstream language of the future. If you want to get a quick look at the go language, here is a simple Chinese version of the "Go language half-hour quick Tour" available on the official Go language website.

Here's what the translation says:

Recently, because of a "why I won't abandon Python to go language" blog, I received a lot of mail, this article, the author said that the go language in addition to "use the return value to handle the exception error" This point, the others are very good. I want to write something that explains why the go language is doing this, which is useful for everyone.

In the go language, the specified method is that the function returns an error message. It's nothing. If a file does not exist, Op. The Open function returns an error message. It's nothing. If you write data to you in an interrupted network connection, net. The Write method in Conn returns an error. It's nothing. This situation is predictable in such a process. This kind of operation is easy to fail, you know how the program will work, because the designer of the API makes it all clear by the result of a built-in error condition.

On the other hand, some operations are basically error-prone, and the environment is simply impossible to give you an error message, and it is impossible to control the error. This is the place where people suffer. A typical example of a program executing a x[j],j value beyond the bounds of an array is painful. Unexpected trouble like this is a serious bug in the program that usually kills the program. Unfortunately, due to the existence of this situation, it is difficult to write robust, self-defending servers-for example, to cope with the occasional bug-like HTTP request processor, without affecting the startup and operation of other services. To solve this problem, we introduced a recovery mechanism that allows a go routine to recover from the error and service the remaining set of calls. However, the cost is that at least one call is lost. This is intentional. Quote from the message: "This design is different from the common exception control structure, which is a decision after careful consideration." We don't want to confuse errors and anomalies as in the Java language. ”

The article I started with said, "Why is the problem caused by an array crossing out of bounds greater than the wrong URL or a broken network?" "The answer is that we don't have an inline parallel way to report errors that occur during the execution of X[j], but we have inline parallel methods to report errors caused by bad URLs or network problems."

The rules for using the error return pattern in the go language are simple: if your function is prone to errors in some cases, it should return an error. When I call other libraries, if it's written like this, I don't have to worry about the bugs, unless there's a really unusual situation, I don't even think I need to deal with them.

One thing you need to keep in mind is that the go language is designed for large software. We all love the simplicity and clarity of the program, but for a large software developed by many programmers, it's hard to keep the program simple by increasing the cost of maintenance. An attractive feature of error handling in abnormal capture mode is that it is ideal for small programs. But for large libraries, you need to consider whether each line of code throws an exception, or if it is necessary to capture it, for some common operations, which is a very serious drag for both development efficiency and programmer time. I felt this problem when I developed my own large Python software. The return error of the go language, admittedly, is not very convenient for callers, but doing so will make it obvious where errors can occur in the program. For small programs, you may only want to print out errors and exit the program. For some very sophisticated programs, depending on the anomaly, the source differs, the program reacts differently, which is common, and in this case, the try + catch approach is verbose relative to the error return pattern. Of course, a 10-line code in Python is likely to be more verbose in the go language. After all, the go language is not primarily for 10-line-scale programs.

Raymond Chen's article is the best article I've ever read to explain the problem of abnormal capture patterns:

• Clear, elegant, but wrong.
• Cleaner, more elegant, and harder to recognize

To illustrate this point: the Go language programmer believes that it is important to use error as a built-in type.

Russ

Postscript

Sometimes, you'll find that a non-native goto statement is treated as a method of error recovery, like the longjmp and setjmp in the C language. It's good, but it's best to use it internally. If the caller needs to know the direction of the error recovery, then your approach is not good.