This is a creation in Article, where the information may have evolved or changed. Out of curiosity, I recently started to touch some Go code. I had some knowledge of it before, but I never tried to write it (no need). But now our team has chosen to use Go to develop a project, so I think it's a good chance to get practical experience. So far, I have been studying this language for a long time. At the end of this blog post, I will write more about Go dry. The community is actually not that pleasant, especially for those who advocate the use of Go because of its simplicity. It seems that simplicity has become a buzzword in the Go community, and many people repeatedly mention it, without giving much practical thought. It seems unfortunate to me, because in my opinion, Go is an "extremely simple language": 1. Should not be considered as the main reason to use Go 2. Find other more favorable recommendations from their point of concern 3. Not even true (not really simple) in this article, I want to analyze some simple ideas around Go. * Before going any further, I would like to emphasize one thing *: This article is not a criticism of go, but a way to promote and advocate go. Sometimes I may criticize some aspect of the language, but this is not the focus of our attention, I will only try to use a kind of informal, factual, each language will be involved in the way to tell. # # Where I come from work and hobbies, I use multiple programming languages at the same time. I don't agree with the concept of "favorite language". I used to have some favorite language in the past, but this kind of cognition is often a momentary emotion, which will change over time. In my work, I used ' C + + ' and ' Python ' to write back-end code for large services. I used to work on an operating system that you might know, and I did embedded work. I did all sorts of other things in my spare time project. I'm not bragging (I'm not an expert), I just want to show that I have at least some insight in many areas of programming, and I've been trying to keep an open mind. So, don't worry, let's start the discussion and take a look at a few points. # # 1. "Go has very few keywords compared to mainstream languages" I started with one of the most common examples. This will be a mantra for everyone when it comes to promoting Go. First of all, even if it is true, I don't know why the number of keywords is an important basis for judging the learning curve or complexity of a language. Of course, if there are thousands of keywords, this could be a problem. But most languages have a maximum of dozens of keywords, and at this scale, the number of keywords is irrelevant. I haven't heard anyone complaining about a language because of the number of keywords. Second, the so-called "little" keyword is actually just a smart lawyer's trick (maybe I might even consider it a false ad for go). [Go Specification] (https://golang.org/ref/spec#Keywords) lists 25 keywords, which is certainly less than most languages. But in my opinion, go does not have the concept of less than other language keywords, while go does not have these keywords, but the corresponding concept is still part of the language (i.e. the actual complexity remains the same). To illustrate what I mean, consider a ' while ' loop. Go does not have this keyword, it is true, but it still has a while loop, [document] (HTTPS://TOUR.GOLANG.ORG/FLOWCONTROL/3) Even so, its purpose is simply to reuse other keywords. Another example of this is ' private ' and ' public '. Go doesn't have these keywords, but it still has ' private ' and ' public ', it just uses the letter case instead of the keyword. Another technique used to prune a keyword is called [pre-defined identifier (predeclared identifiers)] (https://golang.org/ref/spec#Predeclared_identifiers), which technically is not a keyword , but still need them in practice, it's still not a good idea to create a variable with the same name, so finally it seems ... They are basically keywords. In addition, some of these predefined identifiers are keywords in other languages, so it is not fair to compare them to the list of Go keywords. It's like apples and oranges. # # 2. The receiver parameter [receiver parameter] (HTTPS://TOUR.GOLANG.ORG/METHODS/1) is a bit odd for me. It seems that Go does not seem to suggest using ' this ' and ' self ', but still requires methods, so there are "receiver parameters", which are essentially the same except that the method signature looks strange. There is a problem with the receiver parameter, and when accessing a method, I need to know the name of the receiver parameter (which is arbitrary) to clarify the effect of this method. Syntax highlighting becomes a problem because of the lack of keywords (such as this). (see?) This is an example of how to reduce the fact that keywords actually make things more complicated. This is a bit like the implicit ' this ' in ' C + + '. Here's a couple of easy-to-confuse [examples] (https://stackoverflow.com/questions/17932722/go-difference-between-parameter-and-receiver). With all due respect, the simplest and most straightforward way to express a receiver is [Ufcs] (https://En.wikipedia.org/wiki/uniform_function_call_syntax), rather than C + + or Go way. But like I said, I'm not complaining about Go, I really don't mind the argument of the recipient (if I can't stand the weird C + +, I can tolerate go). # # 3. function return value if the receive parameter is not enough, the function can even be declared by the return value in various forms. The usual language allows you to return a value in a function through the ' return ' statement. In the Go language, you can return multiple values (I think it can be solved in a more elegant way by tuples, but that's it). In addition, there are [named Return values] (HTTPS://TOUR.GOLANG.ORG/BASICS/7). In my opinion, it's not a good idea, because it allows us to write confusing code where the return value is hard to find. In combination with the receiver parameters, you can create such a function signature: ' ' Gofunc (f Foobar) Something (a int, b int, c int) (foo int, bar int) {//...} "This is a valid Go code. As you can see, there are three parameters. I really don't want anyone trying to choose this "simple" because this syntax is nothing but simple. # # 4. "No Inheritance" go (perhaps just the community) seems very opposed to "traditional OOP" (regardless of which, perhaps Java or C + +), I remember someone saying that Go is not inherited is a good thing. In addition, go has a function called [embed] (https://golang.org/doc/effective_go.html#embedding), this document as well as some blog posts claiming that Go does not inherit. I try to use it in a variety of ways and I can't think of Go against inheritance. The document linked above says:> also has an important means of distinguishing between embedding and subclasses. When a type is embedded, the method of that type becomes the method of the outer type, but when they are called, the recipient of the method is an internal type, not an external one. Is it different? Inheritance usually works the same way, and inherited methods work on internal types as well. In my opinion, the real only difference in Go is that polymorphism is decoupled from the structure. You need to use the interface to use polymorphism. But once you do, the things you do are very similar to the traditional OOP, including the method overlay-[Here is a demo] (https://play.golang.org/p/DRozP3HCAk). There's something about Go that surprises me-the so-called simple language-you can even achieve multiple inheritance. * * It's really badCake. * * [Golang-nut's mailing list] (https://groups.google.com/forum/#!topic/golang-nuts/fRfkPNlA7Pk), it was mentioned that Go does not deal well with the ambiguity of inheritance. I have tweaked the code mentioned so that it shows the famous "Scary Diamond problem" (dreaded diamond Problem): "Gopackage mainimport" FMT "type T1 struct {t2t3}type T2 struct {t4foo int}type T3 struct {t4}type T4 struct {foo int}func main () {t2: = t2{t4{9000}, 2}t3: = t3{t4{3}}fmt. Printf ("foo=%d\n", T2.foo) fmt. Printf ("foo=%d\n", t3.foo) T1: = T1{t2,t3,}fmt. Printf ("foo=%d\n", T1.foo)} "[Run the above code online] (Https://play.golang.org/p/cSCLyGHssR) above does not have any compile-time warnings or errors. [This is a similar code for C + +] (Https://ideone.com/gfKYqR), you can see that it compiles without ambiguity because there are ambiguities. What would be the result? First, I think that with multiple inheritance, it's almost impossible to use the word "simple" when describing the programming language. * * After I see the code above, no one can persuade me that Go is one of the simplest languages, not even a simple language. * * There are not even other things you can do with embedding, such as embedding through pointers or embedding interfaces with pointers. (I'm not even sure what these features really mean.) Second, I want to make a short, critical critique of the Go language itself. Not dealing with such ambiguity seems to be a design or implementation error. Even C + + is not so crazy to let this code compile through. That's enough to tell you something. # # 5. Error handling various error handling often leads to a huge war of words. I don't want to talk about it. I've used all the usual error-handling styles in different languages (I think), and I don't like all of those languages. I think that error handling whatever has always been a ' PITA ' (a metaphor that should be foreign). To change one style into another, you just need to change a set of questions into another one. There's no good way. Back to the simple topic: Go lets me choose not to use exceptions, which makes things easierThe The characteristics of multiple return values do not make things simple, which means that you cannot return an error or a successful result, you can return all values or not return (' CS ' term, you can say that the problem is a product type rather than a summation of the usage). In fact, I've seen a lot of code reviews for newcomers. If go does not allow multiple return values, and there are some suitable or preferred types, in my opinion, this will make things easier. For the same reason, it is fairly easy to ignore errors in Go or not to report errors to callers or other appropriate destinations. The other is not simply panic. Don't get me wrong, I understand why it exists in Go and its usefulness, and in fact, other languages have similar treatments. I am only proposing as an argument against simplicity. With all due respect, for a newcomer, it is possible to confuse the difference between error and panic and when it is appropriate to use it. # # 6. Generics this topic and error handling, may be a bigger worm. Like errors, I just want to consider the complexity or simplicity of the place. Many people in the Go community seem to think that generics are inherently complex (= bad, mmm-hmm), and there is such a huge overhead. It's true in some ways, but I don't think it's as bad as some people describe. It seems that those people have experienced the pain of the ' C + + ' template, and since then, any mention of generics will be subject to PTSD (post-traumatic stress disorder) attacks. See the people here, * * Generics are not a monster * *. They certainly should not be as complex as ' C + + ' (or some other strange language). I mean, even the front-end people have been working with generics for a while (TypeScript, Flow, ...). If they are not afraid of generics, other programmers should have no reason to fear:) (sorry, front-end developers, just kidding.) It is not yet realized that if generics are used correctly, it can make it easier to use many types and functions. For example, consider [heap interface] (https://golang.org/pkg/container/heap/) in Go. This is how the interface is declared from a heap: "' gopopped: = heap. Pop (&someheap) Myfoo: = popped. (*foo)//ZOMG What just happened to explain this to the new couple, including the panic question. Maybe you can think about what would happen if they didn't really put the whole ' interface{} ' right. By contrast: "' gomyfoo: = heap. Pop (&SOMEHEAP)//MyfoO has the correct type ' ' which is easier to read and easier to interpret (you explain it, just as you will explain that the ' map ' type already exists in go! ）。 And it's more difficult to mess up when writing code. The lack of generics is the cause of additional complexity, and it also causes considerable complexity in other parts of Go, mainly the need for various "magical" functions/types. ' Map ', ' slice ' and ' channel ' types of magic, as well as the accompanying ' make () ' function, which are their three constructors. The ' slice ' type can be either a reference to an array or a dynamic array. (no matter what happens, "do one thing and do it well"?) (just to remind everyone that I don't mind this, just to mention it for a simple argument.) ) # # 7. Other I think I've ruled out the main simple violators. There are only a few simple ones on my list: 1. ' <-' and '-I ' operators. These may be just ' channel ' types of methods. 2. ' Iota '-basically the same, but strange enumeration. 3. Built-in plural. 4. [If support phrase] (HTTPS://TOUR.GOLANG.ORG/FLOWCONTROL/6) (sometimes may be useful, but ' if ' syntax is more complex than other languages) I think that's it. may have forgotten something, but I think it's enough. So, I think if it's not simple, what does Go actually bring? # # task-"Goroutines" This may seem a little obvious, because ' Goroutines ' is a feature that is often mentioned, just like "simple", so I think it's important to differentiate: I don't think it's the usual concurrency, it can't be considered the advantage of Go. Don't get me wrong, the concurrency of Go is no problem. It's just that there's nothing special about it. You have the channel, which is sure to be good, but basically, they're just like the concurrent queues I used elsewhere. Then you have regular concurrency primitives, like mutexes, read-write locks, condition variables, and so on. You can sync your code and you may experience competition conditions and deadlocks like many other languages. I like ' goroutines ' (except the obvious fact that they are lightweight user-space threads) is how they can use I/O-How to dispatch low-level I/O APIs connected to the host operating system (such as Epoll, Kqueue, IOCP ... ）。 This is often difficult for programmers to make pleasant and useful things, especially when compiling native languages. I still know the details here, but in my opinion this is a good practice and why I think Go is a bright spot for future projects. As already hinted,I also like Go this language compiled into native code. It's great to see the new language use garbage collection to keep this incredible effect. (or other forms of automatic memory management-' Swift ' mentioned) # # Conclusion So, readers, why did all this leave you? is Go complex or is it some other reason? Of course not, it's definitely not as complex as ' C + + ' or ' Haskell '. In contrast, Go is really simple. On the other hand, when it comes to comparing the complexities of Go and other common languages such as ' Java ', ' JavaScript ', ' Python ', and so on, the situation is less clear, as I hope. (In addition, this is a difficult, not clearly defined task.) I can provide a similar example. In some ways, Go may be simpler than these languages, and some are not ... In general, I would say that it is almost the same as the average of other common languages. I don't think it's easy, either in the sense or in the actual use, the ultimate experience is important. Finally, where does this article come from and who is the author? I'm not sure. I don't know if go will be selected as a project in my daily work, or if I can use it for hobby projects. I would like to avoid a part of a community promotion like the dogma mentioned in this article. Is there a place of ideological orientation? You are free to make suggestions on this. I have the same problem with the ' Rust ' community, please don't mind, I also know it would be better to leave those more enthusiastic supporters. (Q: "Can you rewrite your project in ' Rust '?") "A: Lost") Perhaps this is the nature of these new languages, and their struggle to inspire people to inspire so much sunshine.
via:https://medium.com/@bob. Clark_34506/go-is-not-very-simple-folks-3e84220e73c7
Author: The other Bob translator: Deadvia proofreading: polaris1119
This article by GCTT original compilation, go language Chinese network honor launches
This article was originally translated by GCTT and the Go Language Chinese network. Also want to join the ranks of translators, for open source to do some of their own contribution? Welcome to join Gctt!
Translation work and translations are published only for the purpose of learning and communication, translation work in accordance with the provisions of the CC-BY-NC-SA agreement, if our work has violated your interests, please contact us promptly.
Welcome to the CC-BY-NC-SA agreement, please mark and keep the original/translation link and author/translator information in the text.
The article only represents the author's knowledge and views, if there are different points of view, please line up downstairs to spit groove
2,903 reads ∙1 likes
