Go language Big God pro-statement: Calendar Seven robbery can become a programmer!

"1": Do you believe that you can use go to do object-oriented programming?

After going through a Go app tour, you might start thinking, "How can you make this language more like an object-oriented programming language?" Because you are used to this kind of programming, you want to make robust code, want to polymorphic.

Then you say: "There must be a way to achieve it!" Then you find the structure embedding, which can intelligently delegate the methods from the enclosing object to the embedded object without repeating the code. This is simply too great!

Of course, you'll soon find that this doesn't really solve the problem. Because struct embedding allows only delegate method calls, it looks like you are dispatching in a multi-state method, but the relationship is not is-a, but has-a, the receiver of the method call is not the enclosing object, but is always the embedded object of the delegate method call.

So, you see, don't try to do object-oriented programming in go?

"2": Do you believe goroutines will solve all the problems?

Before using it, you were fooled by the "easy to run concurrency code through Goroutines", all you had to do was use the GO keyword and run all functions or method calls at the same time. You will naturally think of maximizing the efficiency of your code by allowing code to run concurrently. The Goroutines is created automatically through function calls and even the caller is unaware. Yes, it does. All the code is running at the same time, but it makes the code more complicated.

Go allows users to create millions of goroutine without sacrificing too much efficiency, so should you really use goroutine? You need to know that parallel code is more difficult to maintain and debug than code that flows in a single thread. When accessing from multiple goroutine at once, do you want to consider whether the shared object is synchronized correctly? is the execution order absolutely correct? Does the goroutine actually quit when it is no longer needed?

Therefore, Goroutine is not omnipotent, be sure to use it when necessary, and try not to use the goroutine behind the user.

And because you hide this fact by making your function calls automatically create Goroutines, callers don't even need to be aware of this.

"3": Do you think the interface will solve all the problems instead of object-oriented programming?

When you finally realize that the object cannot use polymorphism, you suddenly think of the functionality that can be provided by the interface, which supports the API, so you can use it to write more robust code.

So now when you write the library, you define all the interfaces, just export the interfaces and have a private structure to encapsulate into perrrrfect. It also gives you more flexibility to switch the underlying implementation, because now you have successfully detached the API from its implementation.

Although the interface gives you great power, it is not an ultimate solution. In object-oriented programming, it still does not provide true polymorphism, and you also have to be constrained by an interface that defines only the API and cannot associate all the data with it.

Of course, it is meaningful to export only interfaces in a certain scenario, and when the code size is smaller, the interface is a good method. But if you have a large amount of code, you have to write a lot more code.

If you want to maximize the use of interfaces, you can use them when some types are interchangeable.

4: Do you believe the channel can solve all the problems?

After you have been through the twists and turns and tried a variety of ways to make the National salvation without fruit, perhaps one day a flash, "and so on, and the channel." ”

The channel implicitly handles concurrent access, and you believe that the channel can skillfully handle synchronization, return values, and use SELECT statements of various channel for flow control.

Yes, the channel is useful, as well as your original intention, and it provides a primitive for passing values between goroutine. However, slowly you will find that there are many problems with the go language using the channel, such as timeouts, blocking I/O, synchronization problems, etc.

So, you have to understand that the channel is a very concise structure, but if it is abused it can lead to more complex and difficult-to-debug code.

"Calendar robbery 5": "Hum, go language is generally like, which has everyone said so Strong"

"Why?" Why? Writing go code is too painful, it has not allowed me to write in my own way. "After experimenting with various methods, you find that none of them solves the problem of polymorphism and concurrency, and you even start to doubt the rationality of the Go language, and you feel deprived of all the good structures and tools available in other languages.

You think it's absolutely necessary to use more powerful tools to express abstract ideas, and go just doesn't cut it.

However, you forget that all languages are restrictive, and you can't just want the language to run according to your ideas, regardless of the original intention of the author to design the language.

"6": You're starting to realize that the first 5 stages are actually what you're imagining

At this stage, you basically give up all sorts of clever tricks and decide to write go code based on the way most standard libraries are written.

At this point you still have an idea: I don't want to accept the go language approach. But at this point, everything starts to get interesting.

While I had to abandon object-oriented programming to embrace the go language, I had to accept the fact that it was too difficult to write concurrent code. I have always believed that the focus of language is to get programmers to write more concise code, so a language is enough to write complex code, but by removing some key tools, the resulting code is easier to write.

"7": Feather The Immortal

At this stage, you have completely accepted go, you can use go to write all the content, including Perl/ruby/python content. You are beginning to realize that there is no mistake bothering you; You must use Goroutines and channel,

Because you are gopher, you will feel honored that the Go language allows you to write code like this.

Congratulations, now you are a Go language programmer!

Go language Big God pro-statement: Calendar Seven robbery can become a programmer!