Evolution go

GopherCon 2015, which came to an end and lasted from July 7 to 10 in Denver, was marked by a considerable number of interesting speeches. Video reports are not yet available, however, summaries of some of them are available in English at this address ; In the official blog you can also read the speech of Ras Cox . The readers are invited to summarize the report on the history of the creation of the language, which opened the second day of the conference.

Robert Grismer ( @robertgriesemer ) is a Google developer, one of the authors of the Go language. In the past, Robert worked on generating code for high-performance JavaScript, was engaged in the Sawzall programming language and in developing a modern implementation of Smalltalk — Strongtalk . According to his own statement, he "spent too much time in the virtual Java-machines, but did not understand how to use them."

Robert's interest in programming languages ​​arose when meeting Pascal - until this point he mainly wrote on BASIC. As a graduate student, he studied with Niklaus Wirth, the creator of Pascal.
')
When Robert finished his studies and plunged into the real world of the professional programming industry, he felt as if he had made a huge step back. While studying at the academy, he used Oberon, a language that allows a programmer to achieve very high personal effectiveness. Now, Robert spent his time thinking about programming languages ​​in the hope of finding a way to get back to the previous level of performance. After 15 years of C ++ programming experience, he realized that he had only two ways ahead: either to sell or to save himself. Together with Rob Pike and Ken Thompson, they chose the second option.

Origins

Go started with a well-defined goal: Google needed a language that was better suited for their work. In addition to this, Robert had a personal goal - he wanted to have at his disposal a small, clean, compiled language with modern functionality that would remind him of what he was used to during his years of study. He dreamed of a "Lego" - simple and composable.

It was not difficult to understand what was wrong with C ++ - it was a very difficult, difficult to understand language that lacked competitive support, which did not scale and whose build time was really big. The following procedure became generally accepted at Google: if someone had a problem with C ++, he would send an email asking for advice, and each person reading would respond to it differently. As a result, at the end of the day, C ++ gurus from the team (who wrote a book on the subject of the question) gave the final answer. It was obvious that such a process was no good.

Robert and the company had good ideas about how to solve these language problems; However, at first only some of these ideas contained specifics. It all started with the installation of the following landmarks:

1. Simplicity, safety, readability are paramount. However, the simplicity of the language does not mean that the product created on it should be simple - sometimes it is just an impracticable condition.
2. Striving for orthogonality in language design. It meant a lot of language tools that would not overlap with each other and which could be easier to combine (combine) and make compositions (compose). The authors wanted to have only one way of writing a particular construct.
3. Minimalism: there is only one way to write some piece of code (for this rule there are now a few exceptions - for example, definitions of variables)
4. It's all about the expressiveness of algorithms, and not in the type system.
5. The lack of desire to adapt the language to any one way of use (for example, the developers did not want to make the writing of lock-free algorithms super-simple, because this area is of interest for only a few experts, while most Go programmers do not have to worry about them).
6. Collective awareness of the history of the development of programming languages.

Another key inspiration came from Hoare’s two scientific articles ( CAR Hoare, Hints on Programming Language Design , Communicating Sequential Processes ).

The first notes on language design were written on September 23, 2007; On this day, Rob, along with another Rob and Ken, first brainstormed this topic. Notes from this discussion begin with the following words:

“The starting point is C. There are some obvious flaws in the language that need to be fixed, some obvious rubbish to be removed ...”

Looking back, we can say that many of the ideas that came up to the developers that day survived to the final release of Go:

1. Syntax: notation with leading keywords, big “sweep”
2. Expressions: 5 operation priority levels (instead of 14 in C ++)
3. Explicitly specified sizes of base types, no implicit conversions.
4. Packages and imports
5. Methods with explicit indication of the receiver parameter ( receiver )

Many of the concepts were lost along the way, however, even more ideas did not survive until the implementation. Go critics love to notice that “there is nothing new in Go,” but they miss the fact that this is a good quality for a programming language. To quote Alan Kay, “most ideas come from previous ideas”; Hoare in 1973 put it even more precisely: “The task of the designer of a programming language is to consolidate ideas, not innovations.”

Since only three people were involved in the design process, the favorite ideas of each of the authors of the language were carefully considered and no one left offended.

Story

Algol 60 (John Backus, John McCarthy, Alan Perlis, 1958-1960) :
Reference point for everything. This language was a fusion of the best ideas taken from Fortran and Lisp. Advanced language for its time. Hoar said about him, "Here is a language that is so superior to its time that it is destined to become the best not only in relation to its predecessors, but also descendants." In the language, block structures, nested and recursive functions, type declarations, “for” instruction, return operator “return”, semicolon-separated operators, “begin / end”, “call by name” blocks, and much more appeared Today it seems to us always existed.

The heirs of Algol - C and Pascal - had a direct impact on Go.

Pascal (N. Wirth, 1968-70):

BEGIN / END for blocks, semicolons as delimiters, left-to-right declarations, structured data types, the concept of predefined standard functions, created for teaching.

C (Ritchie, 1969-73):

Curly brackets for blocks, a semicolon as a sign of instruction completion, use of mimic declarations (variable declarations look the same as usage), duality of pointer arrays, static typing with weak coercion, designed for writing Unix kernel.

In turn, Pascal inspired Modula and Oberon, which had a significant impact on Go.

Modula, Modula-2 (Wirth, 1978-1980):

Modules for independent compilation and encapsulation, cortinos and monitors, support for low-level programming.

Oberon (Wirth, 1986):

Simplified modules. Attempt to clean Modula-2 to as small a language as possible.

Object Oberon (Templ, 1989):

Oberon dialect with classes and methods.

Oberon-2 (Wirth, 1991):

Recycled Object Oberon; Oberon with methods on records (structures)

Compare 2 snippet code on Oberon and Go:





As you can see, despite the different syntax, the structure remains the same. The Go code consists of C operators, but the structure looks like Oberon. This is not surprising: Go uses the quintessence of successful language concepts, while developing it. Oberon’s legacy is as visible in Go as C’s legacy is due to concepts such as packages, imports, strict memory security, GC, and dynamic type checking.

Object orientation and generics

In the 90s, programming languages ​​found the “madness” of type systems:

1. C ++, Java, other languages
2. complex OO type systems
3. complex type systems for generics

Also at this time there is an active distribution of dynamically typed interpreted languages ​​(Perl, Python, Lua, Javascript, Ruby, Erlang).

In the 00s, the reaction movement begins to gain momentum: it turns out that a complex object-oriented code is hard to read; Many complain that the "spaghetti code" of the 70s has returned from the next world. Many languages ​​have an overly cluttered notation ( “public static void” ). In addition, people begin to realize that large programs in dynamically typed languages ​​are hard to maintain.

However, it was obvious to us that Go needs some support for object orientation. In this case, the inspiration was served by Smalltalk (Kay, Ingalls, Goldberg, 1972-80). In Smalltalk, everything is an object; The message can be sent to any object.

In Go, the authors of the language wanted to achieve the power of type safety without using the type system itself. Traditionally, objects contain information about types, which binds object types to "classes" and limits them. A key insight for Go authors was the idea that methods can be attached to any type, if the interfaces carry type information instead of objects. As it turned out, methods and interfaces are the only additional mechanisms that are needed to support object-oriented programming.

Competitiveness

Competent support for competitiveness was planned from the very first days. However, on this topic, Rob Pike can better tell than a speaker. Therefore, it is recommended to look at the Pike reports and read the articles:

1. “Newsqueak” (Pike)
2. “Communicating Sequential Processes” (Hoare)

Generics

Generics is the only serious language feature missing in Go. New Go programmers often lack them; However, generics are rather a mechanism of the typing system, from which the authors wanted to escape, and therefore it is not clear whether they are really necessary language tools.

Generics are incredibly complex both in their semantics and implementation; there are certain trade-offs with which you will have to reckon: for example, you will have to choose whether you want to have a larger binary, or a slower binary, or write more source code. In addition, generics cannot be considered an orthogonal solution — they interact with many other language tools and confuse them.

The thoughts expressed are not based on a bare theory - the authors of the language tried to implement prototypes of generics on Go, but failed to find a good solution, with the result that the case was postponed indefinitely.

Putting it all together

Thanks to Google: they gave the authors of the language an inadmissible luxury, allowing them to spend 2 years running the foundations of the language. The developers acted fundamentally: they added only one function of the language at a time. For example, when adding mappings ( maps ), the authors of the language spent several weeks thinking about their design and implementation. This helped achieve the orthogonal design that Go creators were so eager for.

The three founding fathers (Robert, Rob, and Ken) were very peculiar and dissimilar people; it was therefore not surprising that their discussions were very sharp and often reached a harsh emotional intensity. Because of this, in some places everything did not turn out as well as we would like. But the possibility of having different points of view in one project made the final product much stronger, while later joined Coss Cox helped clean up all the garbage and put everything together. Ian Lance Taylor created a second compiler implementation (gccgo), the existence of which no one suspected until its release. This was a confirmation of the successful achievement of the goals laid down in the design of the language from the very beginning. The implementations differed in detail, and this greatly helped to debug the original compiler and the language specifications. Now language developers have a third frontend for gcc (go / types package), which helps with further testing of compilers and specifications. As it turned out, having 3 front-end compilers for gcc is an extremely useful thing.

Evolution go

Go — , . — , . gofmt ( ) gofix ( API) , - .

, : , , (composite literals), . , .

Go

?

• ( — PL/1);
• : , , ;
• . ;
• ;
• , . Lisp , . Smalltalk , , - .
• : (, ). Sun Java. Java , Sun — .

Go?

2. (, , -)
4. , : , , defer ( Swift)
5. , : , gofmt ( ), go build ( Makefile)
8. - (Go playground)

Go ?

« » « ». Go . . 10 .

. «», , « », :

1. build tags ;
2. ;
3. ;
4. ( , )

, : , .

( )

1. 1960, Algol 60. ( , , — , , )
2. 1970, Algol C Pascal. , .
3. , . “ - , , (Pascal) , (). , , « - » ( , C).”
4. 40 , 2 Go. ( Go , — , — , « »)

, , Go , .

Q & A

Q: , . , ?

A: Go , . - , . .

Q: ?

A: std — , std Plan 9. , fmt Plan 9 ( ), fmt . , , , ; - .

Q: GC?

A: . , ; , lock-free . IBM, GC Metronome. , , ; GC, GC.

Q: Go -. Go -?

A: , Go ; -. UI. , , , , .. . .

Q: Go ?

A: Go : , . «», — , .

Q: , DSL (- )? , Go — .

A: Google DSL Sawzall. , DSL , ; , «» . DSL, , , Go , Go.