The father of Go language talk go: Boulevard to Jane

This is a creation in Article, where the information may have evolved or changed. Http://www.csdn.net/article/2012-07-05/2807113-less-is-exponentially-more
Summary:Introduction: This article is the chief engineer of Google, the father of Go language, Rob Pike himself organized the June 21 in San Francisco to go SF speech. Rob mentions: The Go language is based on C as a prototype, in C + + as the goal of design, but ultimately very different. It is worth mentioning that these 3 languages have been elected tiobe the language of the year.

Introduction : This article is the chief engineer of Google, the father of Go language, Rob Pike himself organized the June 21 in San Francisco to go SF speech. Rob mentions: The Go language is based on C as a prototype, in C + + as the goal of design, but ultimately very different. It is worth mentioning that these 3 languages have been elected tiobe the language of the year.

A few weeks ago I was asked, "What surprises you most about the go language?" "I gave the answer clearly:" Although I want C + + programmers to be able to use go as a substitute, in fact most go programmers are coming from Python and Ruby, with few C + + programmers. ”

I, Ken and Robert were all C + + programmers, and when we wrote the software, we thought we should design a programming language that was better suited to solving the problem. Oddly, other programmers don't seem to care.

Today I'll talk about what makes us decide to create the go language and its unexpected results. I'm talking more about go than C + +, so it doesn't matter if you don't understand C + +.

The main thrust can simply be summed up as: Do you agree with less are more or not?

Here's a real story. The Bell Labs Center would have allocated 3 digits for the code: the physical search was 111, the computational science search was 127, and so on. In the 1980s, with a further understanding of the search, we felt it was necessary to add more digits to better characterize the work, so our center was 1127.

Ron Hardin Half-joking that if we really understood the world better, we could have removed one digit and turned 127 into 27. Of course, the managers didn't believe the joke, and Ron didn't expect them to believe it, but I think it's very philosophical. Sometimes less means more, the deeper you understand, the more capable you can be.

Please remember this idea.

Looking back on September 2007, I was doing some trivial but core work for Google's huge C + + program (yes, that's the one you all used!) ), it takes me 45 minutes to work on Google's vast distributed compilation cluster. Then a few of the C + + Standards Committee's Google employees gave us a speech, and they introduced us to what's new in the next c++0x (now called c++11).

In that one-hour speech, we probably heard about 35 new features in the plan. Of course there are more, but in that speech we only heard about 35 kinds. Some features are relatively small, of course, any one of the features mentioned in the speech can be called iconic: some are more subtle, but difficult to understand, like rvalue reference (RValue Reference), others have C + + features, such as variadic template; there are just some pretty crazy ones, As user-defined text (user-defined literal).

At this point, I asked myself a question:does the C + + committee really think that C + + is not much of a feature? Of course, unlike Ron's jokes, simplifying this language must be a greater accomplishment! Maybe it's ridiculous, but please keep this idea in mind.

A few months before that C + + speech, I made a speech (you can see it on YouTube) about a toy-sex concurrency language that I developed in the 80 's. That language is called Newsqueak, the predecessor of Go.

I did that speech because I forgot some good ideas in the newsqueak when I was working at Google, and now I'm looking back. I'm sure it will simplify server-side code writing, and it's good for Google.

I actually tried to add this idea to C + +, but it failed. Combining concurrent operations with C + + control structures is difficult, which in turn means that even a successful profit can be very small.

But c++0x's speech made me rethink it again. The new C + + memory model uses atomic type, which bothers me, and I don't think Ken and Robert would like it either. It's not a good idea to add such a detail to a type system that's already overloaded. This may seem shortsighted, as hardware can change significantly over the next 10 years, so tying the language to today's hardware is not necessarily the right choice.

At the end of the speech, we went back to the office. I started compiling again, and I turned my chair around for Robert and started asking some key questions. Before the compilation was over, we persuaded Ken to decide to do something together. We don't want to use C + + anymore, and we want to be able to use the parallelism feature when we write Google's code. The issue of "Big Code" is also a concern, but we finally decided to resolve the problem at last.

Then we found a whiteboard and wrote down what we wanted to do with it. Here we only focus on the big aspects, grammar and semantics these details of things first put aside.

Then we communicate in the mail, here is the content selected:

Robert: The C language as a prototype, repair some of the obvious flaws, remove the garbage function, add some missing features. Rob: Named "Go", there are many benefits, the name is very short, easy to spell. Tools can be called: GOC, Gol, Goa. If there is an interactive debugger/interpreter can also simply call it "go", suffix name with. Go. Robert: Define NULL interface syntax: interface{}. All interfaces are implemented through this, so you can use it instead of void*.

We didn't design all the functions from the beginning, and it took us a year to determine the array and slice features, but there are a lot of language features that have been identified in the first few days.

Note: Robert says to use the C language as a prototype, not a c++!. But we're not really starting with C, just borrowing some of the content, like operators, parentheses, and several identical keywords. Of course, in order to make it the most suitable language for us, we have borrowed some features from all the languages we know.

The final result is undoubtedly very different from C or C + +. The following are simplified functions for go from C and C + +:

• Canonical syntax (no symbol table required to parse)
• Garbage collection (Exclusive)
• No header file
• A clear Reliance
• No cyclic dependencies
• Constants can only be numbers
• int and Int32 are two types of
• Case-Letter setting visibility (sets visibility)
• All types (type) have methods (not types)
• No subtype inheritance (not subclass)
• Package-level initialization and explicit initialization order
• The files are compiled into a package.
• Package Package-level Globals presented in any order
• No numeric type conversions (constants are auxiliary)
• Interface implicit implementation (no "implement" declaration)
• Embedding (not promoted to Super Class)
• Method according to function declaration (no special location required)
• Method is a function
• Interface only method (no data)
• method is matched by name (not type)
• No constructors and destructors
• Postincrement (such as ++i) is a state, not an expression
• No Preincrement (i++) and predecrement
• Assignment is not an expression
• Definite assignment and Calculation order in function call (no "sequence point")
• No pointer arithmetic
• Memory is initialized with a value of 0.
• Local variable value legality
• There is no "this" in the method
• Fragmented stacks
• No static and other types of annotations
• No templates
• No exception
• Built-in string, slice, and map
• Array bounds checking

Because there are so many features to simplify, I believe go is more expressive than C and C + +. Less can be more!

But it can't be discarded. You need to divide your ideas into modules, such as how the type works, the syntax that can actually run well, and what helps ensure that the class library interacts.

We also added things like C and C + +, such as slice and map, compound text (composite literal), top-level file expressions (which is a big problem, but often overlooked), mapping (reflection), garbage collection, etc. We are also very naturally involved in concurrency.

There is obviously a lack of type hierarchies, which makes me very angry.

The first time I set sail in the go language, I got a "I can't work in a generic environment" feedback, which is really a strange comment.

To be fair, I think he might have been using STL in C + + for a reason. In the literal sense, this means that writing an int list or a string map is a huge burden to him. I'm not going to spend too much time on this weird problem, so it's the same with generics support.

But more importantly, only types are used to solve such problems, neither polymorphic functions (polymorphic function) nor language primitives (language primitive) or other types of help, only types!

This is the detail that stuck to me.

Programmers who move from C + + and Java to go are nostalgic for the way they use type programming, especially concepts such as inheritance and subclasses. Maybe I'm just a layman about "type", but I really don't see any good in templates.

My late friend, Alain Fournier, told me that he believed that the most basic requirement of academic work was division of labor. Do you know? The type hierarchy is also just a taxonomy. you need to decide what is encapsulated in what, what is the parent type of each object? is a inherit B or B inherit a? Can the sorted array be used to sort the array or is it an array-implemented sequencer? If you believe in the type decision design then this is the problem that must be cleared!

I think it's a ridiculous way of thinking about programming. What really matters is what these classes can do for you, not what is the relationship between them!

Of course this is the interface in the go language, but this is only part of the rule, and the Go language design concept is actually much more complicated than this.

If C + + and Java are about class hierarchies and classifications, then the core idea of Go is the combination (composition).

Doug Mcilroy,unix, the ultimate inventor of piping principles, wrote in 1964:

When we need to integrate data in a different way, we need some kind of garden-like hoses to couple the programs together, as do the IO processing methods.

The same goes for go.--go taken from this idea, but further-it is a combination of the language and the connection.

For example: The interface provides a combination of methods, so long as the implementation of the method M can be placed directly there, no matter what it will be appropriate.

Another example is about how concurrency gives us the ability to perform independent computations.

Go has a very unusual but very simple type composition: embedding. These combination technologies are unique to go and are very different from C + + or Java programs.

Although this is not very relevant to the design of Go language, I would like to say:go is for large-scale programming, need large team to write and maintain.

Large-scale programming is generally considered to be the domain of C + + and Java. I think it's just a matter of history and perhaps an industrial accident, but it's generally thought to be about object-oriented design.

I disagree with the idea that big software needs to be defined, but it's even more important to rely on management, clean interfaces, abstractions, and good documentation tools! Unfortunately, none of these are the strengths of C + + (but this is obviously much better Java).

Of course, I'm not sure yet, because there are not enough programs written in the go language, but I believe go will be a great programming language for large programs. Time will prove everything!

Now, back to the center of our speech:

Why has go been designed for C + + as a goal, but not a C + + programmer?

Joke that this may be because go and C + + design ideas differ greatly.

C + + wants all solutions to be easy to get/use. I saw this sentence on the c++11 FAQ (FAQ):

C + + is capable of gracefully, flexibly, and 0 of the cost of abstracting things, much more efficient than specially written code.

This way of thinking is different from the way go works. 0 cost is not the target, at least 0 CPU cost is not. The goal of GO is to liberate the programmer!

Go is not all-encompassing, you don't expect it to be anything, and you can't control every detail with precision. For example: Go has no raii, but you can use a garbage cleaner instead, although you can't even use the memory deallocation function.

You can get a lot of easy-to-understand but powerful toolset from go to combine the problem-solving solution. It may not be as fast or as refined as other languages, but it is certainly easier to write, easier to read, easier to understand, and perhaps more secure.

From another point of view, go must be more streamlined:

Python and ruby programmers turned to go because they did not need to learn more about it and were able to get better performance and even use concurrency features.

C + + programmers are reluctant to go because they do their best to take full control of their own programs and do not want to change them. For them, software is not just about getting the job done, but doing it.

The problem now is that if go succeeds, it will subvert their worldview.

and We should have noticed at the outset that people who are interested in the new features of c++11 are not interested in a language that is so concise, even though it can do more work.