Go design philosophy: less is more, where does that come from?

When I shared knowledge and experience in the Go community before, I often heard slang words such as: less is more, less is more, the road to simplicity, the road to simplicity, etc.

Even when discussing Go issues and proposals, some people will use "less is more" to refute or support arguments, which is very interesting. Everyone will be very curious, where does it come from and what does it mean?

Source of the golden sentence

Such a deeply rooted community cultural concept must have been proposed by someone with a core. He is the author who said this:

Does anyone recognize it?

He is Rob Pike, the father of the Go language.

Rob Pike has mentioned something like “less is more” on multiple occasions, and it’s a widely circulated idea.

Share on occasions such as:

• In 2012, at the Go SF conference, "Less is exponentially" was shared more^[1]》, this is the earliest article sharing compiled from public opinions.
• In 2015, what was shared at the dotGo conference was "Simplicity is Complicated^[2]", which continued to instill culture and share View.

Various variations of this view are widely circulated in the industry, forming a unique "culture" of the Go community.

Of course, judging from the response from the community, there are both praise and criticism.

Speech content

Here is a quote from Rob Pike's "Less is exponentially more^[3]", the text part @MIKESPOOK^[4] Translation, I will reorganize, prune, quote, and illustrate it here, so I won’t reinvent the wheel. I state it clearly.

As shown below:

Background

This is me (Rob Pike) at the Go conference in San Francisco in June 2012 content of the speech.

This is a private speech. I'm not speaking on behalf of anyone on the Go project team, but I'd like to start by thanking the team for everything they've done to make Go possible.

At the same time, I would also like to thank the San Francisco Go community for giving me this speaking opportunity.

What surprised me the most about Go

A few weeks ago I was asked: “What surprised you after launching Go? What's the most surprising?"

I immediately had an answer: Although we hope that C programmers will learn about Go as an optional language, more Go programmers come from Python, Ruby, and only Very rarely comes from C.

We (Ken, Robert and I) were former C programmers ourselves, and we designed new languages ​​to solve problems in the software we wrote.

And other C programmers don't seem to care much about these problems, which seems contradictory.

Why Go was developed

Today I want to talk about what led us to create Go, and why it shouldn’t be the way it is. We were surprised by the results.

I promise to discuss Go more than C, even if you don’t know C you can still completely follow the topic.

The answer can be summarized as: Do you think less is more, or less is less?

The Bell Labs Story

Here is a true story as a metaphor. As follows:

1. Bell Labs was originally identified by three numbers: 111 for physical research, 127 for computer science research, and so on.
2. In the early 1980s, a memo arrived on schedule stating that because the research we knew was growing, in order to easily identify our work, an additional digit must be added. . So our center becomes 1127.
3. Ron Hardin jokingly said, half seriously, that if we really understood the world better, we could reduce it by one digit, making 127 just 27.

Of course the management didn't hear the joke, or maybe they didn't want to hear it, but I think there is great wisdom in it. Less is more. The better you understand, the more implicit it is.

Please remember this idea.

Background on developing Go

C Compile Waiting

Back to 2007 In September, I was doing some trivial but core work on a giant Google C program (the one you all use).

It took me about 45 minutes to compile on that huge distributed cluster.

C New Feature Improvements

Received a notification that several people employed by Google working on the C standardization committee will be doing A report.

They will tell us about the improvements that will be made in what was then called C 0x (now known as C 11).

During the hour-long presentation, we heard things like there were 35 features already planned.

In fact there are more, but only 35 features are described in the report. Of course some features are small but significant enough to be worth mentioning in the report.

There are also some that are very subtle and difficult to understand, such as:

• Rvalue references.
• Variadic templates.
• User-defined literals.

At this point I asked myself a question: Does the C committee really believe that the problem with C is that there are not enough features?

Definitely, in another Ron Hardin joke ,Simplifying the language achieves far more than adding functionality. Of course this is a bit ridiculous, but please remember this idea.

Experimental language attempts

Just a few months before this C report, I myself gave a speech, which you can see on YouTube, about a toy-like computer I developed in the 1980s. Concurrency language. This language is called Newsqueak, and it is the predecessor of Go.

I am doing this report because there are some ideas missing in Newsqueak that I thought about again while working for Google. I was convinced that they would make it easier to write server-side code, allowing Google to benefit from it.

In fact I tried to implement these ideas in C, but failed. It's too difficult to tie C control structures to concurrent operations, and ultimately it makes it hard to see the real advantages.

While I admit I've never been really proficient in C, pure C still makes everything possible It looked too bulky. So I dropped the idea.

But that C 0x report made me think about it again. One thing that really bothers me (and I'm sure also bothers Ken and Robert) is that the new C memory model has atomic types.

It feels like an absolute mistake to add such a microscopic collection of descriptive details to an already overburdened type system. This is also short-sighted. It is almost certain that hardware will advance rapidly in the next ten years. It is very foolish to tie the language too closely to today's hardware.

Go Initial Team

After the report we returned to the office. I started another compilation, turned my chair towards Robert, and started communicating the key issues.

Before the compilation was finished, we had brought Ken in and decided what to do.

We are not going to continue writing C, and we - especially me, want to be able to easily write concurrency when writing Google code.

At the same time, we also want to move forward to control "big programming", which we will talk about later.

Go Feature Discussion

We wrote a bunch of things we wanted and their necessary conditions on the whiteboard. Syntactic and semantic details are ignored, and the blueprint and big picture are envisioned.

I still have a fascinating email from that time.

Here is an excerpt:

• Robert: The starting point is C, fix some obvious flaws, remove clutter, and add some missing features.

• Rob: Named "go". You can make up the origin of the name, but it has a good foundation. It's short and easy to spell. Tools: goc, gol, goa. If you have an interactive debugger/interpreter, just call it "go". The extension is .go.

• Robert: The empty interface is interface{}. They implement all interfaces, so this can be used instead of void *.

We didn’t portray everything correctly. For example, mapping arrays and slices took almost a year. But most of the important features of the language were nailed down in the first few days.

Note that Robert said C is the starting point, not C . I'm not sure, but I believe he means C, especially if Ken is around.

But the fact is that in the end we did not start from C. We started from scratch, borrowing only operators, parentheses, braces, and some keywords. (Of course, we also took the best from other languages ​​we know.)

In any case, we are now doing the opposite of C, deconstructing everything, going back to square one and starting again. We are not trying to design a better C, or even better C. Just a better language for the type of software we care about.

Eventually, it became a completely different language from C and C. Each release is getting more and more different.

Go Feature List

I made a list of important simplifications of C and C in Go:

• Canonical syntax (no symbol table required for parsing).
• Garbage collection (only).
• No header file.
• Explicit dependencies
• No cyclic dependencies.
• Constants can only be numbers.
• int and int32 are different types.
• Letter case sets visibility.
• Any type can have methods (no classes).
• No subtype inheritance (no subclassing).
• Package level initialization and defined initialization sequence.
• files compiled into a package.
• Package-level global expressions are order-independent.
• There is no arithmetic conversion (constants undergo auxiliary processing).
• Implicit interface implementation (no "implements" definition required).
• Embedding (no upgrade to parent class).
• Methods are defined like functions (no special location requirements).
• Methods are functions.
• Interface only contains methods (no data).
• Methods match only by name (not by type).
• There is no construction or destruction method.
• Post-increment and post-decrement are statements, not expressions.
• There is no pre-increment or pre-decrement.
• Assignment is not an expression.
• Execute in the order in which assignment and function call are defined (there is no "sequence point").
• No pointer arithmetic.
• Memory is always initialized with zero value.
• It is legal to take the address of local variables.
• The method does not have "this".
• Segmented stack.
• No static or other type annotations.
• No template.
• No exception.
• Built-in string, slice, map.
• Array bounds checking.

Besides this simplified list and some unmentioned trivia, I believe that Go is more expressive than C or C. Less is more.

But even so you can’t throw away everything. There's still a need to structure the way types work, to have proper syntax in practice, and to make the ineffable things of making libraries interact better.

We also added some things that C or C didn't have, such as slice and map, compound declarations, top-level expressions per file (an important thing that was almost forgotten), reflection, garbage collection, etc. . Of course, there's also concurrency.

Can't imagine without generics

Of course what is obviously missing is type hierarchy. Please allow me to say a few foul words about this.

In the original version of Go, someone told me that he couldn't imagine working in a language without generics. As mentioned somewhere before, I think this is an absolutely magical review.

To be fair, he was probably using his own way of expressing how much he liked what STL did for him in C. For the sake of debate, let's give him the benefit of the doubt.

He said that writing containers like int lists or map strings is an intolerable burden. I think this is an amazing point.

Even in languages ​​that don't have generics, I spend very little time on these issues.

Object-oriented approach

But more importantly, he said types are the solution to letting go of these burdens. type. Not functional polymorphism, not language foundation, or other assistance, just types.

This is the detail that stuck me.

Programmers coming to Go from C and Java miss the programming style of working with types, especially inheritance and subclassing, and all that goes with it. Maybe I'm a layman when it comes to the genre, but I've never really found this model to be very expressive.

My late friend Alain Fournier once told me that he believed that the lowest form of scholarship was classification. So you know what? Type hierarchy is classification.

You have to make decisions about which piece goes into which box, including the parent of each type, whether A inherits from B, or B inherits from A.

Is a sortable array a sorted array or a sorter expressed by an array? If you believe that all problems are type-driven design, then you have to make decisions.

I believe it is ridiculous to think about programming this way. The core is not the ancestral relationship between things, but what they can do for you.

Of course, this is where interfaces come into Go. But they are already part of the blueprint, which is the true Go philosophy.

If C and Java are about type inheritance and type classification, Go is about composition.

Doug McIlroy, the eventual inventor of Unix pipe, wrote in 1964 (!):

We should connect a piece of pipe in some way like a garden faucet to a hose. Connect message data piece by piece. This is also the method used by IO.

This is also the method used by Go. Go takes this idea and takes it a step further. This is a language about combination and connection.

An obvious example is the way the interface provides us with combined components. As long as it implements method M, it can be placed in the appropriate place without caring what it is.

Another important example is how concurrency connects independently running computations. And there's also an unusual (but very simple) type composition pattern: embedding.

This is Go's unique combination technology, which is completely different from C or Java programs.

The Big Programming Pattern of C/Java

There is an unrelated Go design I want to mention: Go was designed for Helps write large programs, written and maintained by large teams.

There is a point of view called "Big Programming". Somehow C and Java dominate this field. I believe this is just a historical mistake, or an industrial accident. But it's a widely accepted belief that object-oriented design can do something.

I don’t believe that at all. Large software does need the protection of methodology, but it does not need such strong dependency management and such clear interface abstraction, or even such gorgeous documentation tools, but it is not more important than powerful dependency management, clear interface abstraction and excellent documentation tools. , and none of these are things that C does well (although Java obviously does better).

We don’t know yet because not enough software is written in Go, but I am confident that Go will stand out in the big programming world. time proves everything.

Why Go is not liked by C programmers

Now, back to the surprising question I mentioned at the beginning of my speech:

Why does Go, a language designed to destroy C, fail to win the hearts of C programmers?

Jokes aside, I think that's because Go and C have completely different philosophies.

C is to let your fingertips solve all the problems.

I quoted this paragraph from the C 11 FAQ:

C has a much wider range of abstractions, elegance, flexibility, and zero-cost expressiveness than the huge growth of specially written hand-coded code.

This thinking direction is different from Go. Zero cost is not the goal, at least not zero CPU cost. Go's proposition is more about minimizing the programmer's workload.

Go is not all-encompassing. You can't get everything built-in. You can't precisely control every little detail of execution. For example there is no RAII. Garbage collection can be used instead. There is also no memory release function.

What you get is powerful, but easy to understand, and easy to use to build some modules that are used to connect and combine to solve problems.

This may not end up being as fast, as polished, and as ideologically clear as your solutions written in other languages, but it will certainly be easier to write, easier to read, easier to understand, easier to maintain, and safer.

In other words, of course, some oversimplification:

• Python and Ruby programmers: Go to Go because they don’t give up much expressiveness, but Gain performance and dance with concurrency.
• C programmers: unable to move to Go because they fought hard to gain precise control over their language and don't want to give up anything they've gained. For them, software is not just about getting work done, but about getting it done in a certain way.

The question then is, does Go’s success refute their worldview? We should realize something from the beginning.

Those who are excited about the new features of C 11 will not care about a language that does not have so many features. Even if it turns out the language has more to offer than they imagined.

thank you all.

Summary

I have always been very curious about Go’s philosophy of “less is more”. Where does it come from and what is its meaning?

I read and sorted it out during the Spring Festival. Although the speech contained a lot of content, it was also more colloquial. But essentially what Rob Pike meant by “less is more” is something interesting.

The core point of view is: "The concepts of Go and C are completely different. It is hoped that the programmer's workload will be minimized. Its small number of features should be able to be connected and combined to solve problems, and it should be more expressive rather than heap functions." .

The above is the detailed content of Go design philosophy: less is more, where does that come from?. For more information, please follow other related articles on the PHP Chinese website!