Interview: Brian Kernigan and Alan Donovan

This year, Brian Kernighan, the author of the classic C Programming Language, co-authored with Alan Donovan, wrote the book The Go Programming Language, which, apparently, is de facto destined to become one of the official sources of initial knowledge of the language - not least because the book was created under the close supervision of the creators of the language itself. The electronic version of the book in English is released only today - the cause of several hyphenation was the correction of inaccuracies made in the first edition of the book; high-quality translation into Russian is expected no earlier than March 2016.

The attention of all interested readers is invited to translate a recent question and answer session with the authors of the book, conducted by the Slashdot resource.
')
A few weeks ago, everyone had the opportunity to ask Alan Donovan and Brian Kernighan questions on their joint work, the book The Go Programming Language. Slashdot selected the most popular questions from readers and received answers to them.

Donovan / Kernighan : Thanks to everyone who took the time to ask us interesting and provocative questions; Alas, all did not answer. In addition, none of us is a member of the Go language development team, so we initially could not give more authoritative answers to questions about future plans or tell in detail about utilities.

OpenGL and LockOSThread

I stopped using Go when I saw how much “harsh” hacks I would have to resort to in order to make libraries like OpenGL work normally. Are there any plans to fix this?

Donovan : The essence of the problem is that many C libraries like OpenGL implicitly use the caller's thread id to store context information. In some cases, this is because the API design was created before multithreading became the norm, when global variables could be safely used to store context information. In other cases, the use of this design is only a matter of convenience, since it allows you to save on the transfer of an additional parameter to each call.

When designing Go, the idea of ​​a local stream storage ( thread-local storage, TLS ) was rejected because of its tendency to organize what is called the “ action at a distance ” ( action at a distance ): allowing the programs to be made only slightly shorter, TLS makes them much less readable (By the way, we wrote about this in the book). Since the absence of TLS in Go is considered to be a feature, there are no plans to fix it. But there is an opportunity to get better to work with Go strongly dependent on the TLS library in C. My colleague David Crawshaw just recently talked about this at DotGo 2015 in Paris.

Why is package versioning ignored?

Why package versioning remains unattended? Do you yourself still like your decision? The more I use Go, the more this moment reminds me of the “Achilles heel” of the language; Software has been around for decades, and its development is a continuous evolution. The import system in Go does not allow you to specify a version or “hint” it, the 'go get' command also does not allow it (although it supports all popular version control systems), therefore various hacks like gopkg.in are invented. And it's not clear what the problem is, because package managers for other languages ​​have already solved this issue in a more or less elegant way ...

Donovan : Go was designed for writing large programs, and it is well known that versioning is difficult to do in such a context.

About ten years ago, an experiment was conducted on Google to introduce versioning into the build system (designed by Rob Pike and others). It failed because of the problem of diamond dependency , about which, I think, many of you have heard - this is a classic problem of version numbering. Suppose there are four packages A, B, C, D, where A depends on B and C, and B and C both depend on D. This is a diamond dependency . If author B decides that only version 1 of package D is appropriate, and author C requires at least version 2 of the same package D, you will receive an impossible set of restrictions. If you are lucky, you can knock A with both versions D, “old” and “new”, but more often than not it will not work. After this experiment, Google never again touched automatic versioning.

The way we now do versioning is simple, but “manual”: we take each version of a package as an independent entity with its own separate name (for example, “D1”, “D2”), and try to limit the number of versions of each package, ideally - to one. This is why versioning is not a priority for us at Google.

However, in August this prolific Dave Cheney proposed a version numbering scheme for packages in Go, so maybe we will see the development of this idea in the future.

Error handling in Go

In its peculiar way of handling errors, Go is very different from other languages. Please tell us about the pros and cons of this approach in comparison with Java in the context of large-scale applications.

Kernigan : In general, Go strongly encourages explicitly handling errors. The functions from the standard library almost all return an error status along with the value of a function, and your code should do something with this status; you can't just ignore errors. In this plan, Go is similar to Java, where you have to catch or throw errors; you can't just do nothing. Yes, this is an annoying inconvenience in the case of small one-time programs, but in the case of large ones, this is a real salvation. And both of these languages ​​do the “right thing,” just each in its own way.

What they differ in is the use of exceptions. There is no exception mechanism in Go, so there is no direct way to handle all errors in one place, which is allowed by try/catch in Java - although the defer operator can help with fixing the place of error handling. All this means that Java code may be a bit more compact (only in this respect!), But perhaps at the price of not having the opportunity to provide accurate information about what went wrong.

In our book on Go, quite a lot of space is allocated to the topic of error handling; in most of the examples, we tried to show how to correctly handle errors — instead of ignoring them, even if this made the final examples a little longer.

Donovan : I wrote a lot of Java code and, in my experience, “good” error handling is equally difficult in both languages. However, Go reduces the syntactic price of adding an error message when throwing it up, since you must write more or less the same code regardless of whether you are going to supplement the error with new information or not. Java, on the other hand, makes it so tempting to avoid writing try/catch/throw blocks that programmers too often recklessly throw errors to the top. It's funny that such pragmatic knowledge of the small differences in the use of languages ​​can never be gained from reading their specifications.

Applicability Go

For which scenarios and projects do you recommend (or do not recommend) to use Go?

Kernigan : Go is a very good general purpose language , and we have no obstacles to using Go to solve any new problem. He seems to be best at showing himself on programs that involve networking or other competitive tasks; Gorutines are a very convenient and efficient thing, but the language also has good support for more traditional approaches to sharing memory. Practice shows that people who write new networking code like Go. Personally, I would use it for any of my tasks, for which earlier I would have had to resort to C, Java or C ++.

Go also gained some recognition as a scripting language, becoming a potential replacement for large Python scripts. This may seem a bit surprising, since scripting languages ​​are very convenient for quickly “throwing” something in a hurry, when you need to make it work faster. Problems come afterwards when the “dropped” code begins to fall with type errors or other errors that could be detected much earlier in any statically typed language. Go does not replace one-liners with Awk, does not replace Python, Perl or Ruby for 10- or 100-string programs, but when the task gets a little bigger and more serious, the combination of type safety and efficiency definitely costs a little more work.

Why should I use Go?

For a person like me who loves a garbage collector, multiple dispatching, as well as extreme abstraction capabilities in high-level languages ​​like Common Lisp, as well as security, error detection at the compilation stage, readability and speed in low-level languages ​​like Ada and Haskell — in What are the advantages of using Go compared to the two types of languages ​​listed? What does Go really bring in?

Kernighan : Actually, Ada, and especially Haskell, are not very similar to low-level languages, and Haskell is usually beyond reach for beginners; but okay, this is all niggles. Go has everything you mentioned in both of your lists of desired qualities (of course, the validity of my statement can be criticized - it depends on what you mean by " extreme abstraction "), but also provides competition (concurrency) in a convenient and efficient way. form; for some types of applications, this gives a serious win.

Donovan : Go looks very simple compared to languages ​​like Common Lisp, C ++, Java, or Python. There are no macros, templates, class loaders (ClassLoader), no metaclasses. These features are the first with which I, like PL Geek, rush to play, when I am writing for the sake of the first programs in a new language, only when we go on a larger scale, they do not mean so much. I can remember a lot of unpleasant days spent debugging over-the-use of C ++ STL, non-hygienic macros on Lisp, or the __call__ method in Python. The Go design regulates that the simplicity, uniformity and recognition of a large code base are more valuable for the team as a whole than the benefits of using everyone within the group of their favorite “muddy” language features to solve each of the tasks.

Go potential

What serious potential in the real world do you see for Go? How do you see the potential of Go in replacing existing open source web stacks like Apache and PHP, Python or Ruby?

Kernighan : The reason God only had six days to create the universe was because he did not have to deal with a previous legacy. Reasoning realistically, none of the programming languages ​​will be able to move completely to replace large code bases - this is simply too much work. Go is often a good choice for new projects or where it was planned to rewrite the existing system anyway; in addition, it can provide a convenient interface for existing code through interfaces of external functions — in particular, for libraries in C. But large-scale replacements of someone’s codebase in general seem unlikely.

Donovan : I agree with Brian that Go is unlikely to help “get rid” of another language or library - but that was never his goal. Rather, Go is an attractive alternative. Much of Go's popularity comes from how simple you can create useful web servers and other distributed systems, using only a few more tools than components of the standard library. The standard library was created quite recently, and experts in creating various systems were involved in it, so third-party servers like Apache or frameworks like Rails are not required for the first steps in developing their applications - although similar frameworks, of course, also exist for Go.

Official IDE for Go?

Is an official cross-platform IDE for Go being developed? Experience shows that the adaptation of the language among the masses can significantly speed up a certain set of tools that you can easily and quickly start using - for example, IDE Android Studio offered by Google. Are there any similar plans for Go?

By the way, how about the GUI - when will I finally have the opportunity to “get down” from C ++ to develop productive desktop applications with an interface?

Donovan : We agree that a good IDE will play in favor of attracting new applicants to try Go, while my colleagues and I gradually came to the realization that (and this is not surprising) most of us use very traditional editors like Vim, Emacs , Sublime Text and even Acme, and this is not what most people think of as an IDE. Notable initiative comes from JetBrains, which this year put together a team to develop a plug-in for Go to IntelliJ IDEA , which will allow everyone to collect, test, debug and refactor programs written in Go, as easily as in any other language.

With regards to cross-platform libraries for the GUI, the canonical solution does not exist yet, although there have already been some interesting experiments like GXUI and Shiny .

Should Go replace Java?

Should Go replace Java as a development / language platform for Android?

Donovan : The developers of the Go language at Google are actively working to ensure that Go can be used to write applications for Android and iOS; if you are interested, see Hanna Kim’s (Google) report at GopherCon 2015 . But now it’s just an experiment, so, as Brian said earlier, Go’s goal is not to replace existing large code bases.

Safe performance

Rewriting the Gnu + Linux toolchain on Go can provide the security that C hasn’t been able to give for decades (I mean the recent bugs in BASH and OpenSSL). Even a small portion of this work would add Android security. Performance in 1.5 and loading libraries will help to make the size of executable files small. Is there a movement interested in rebuilding the Linux base?

Donovan : Go is well suited for utilities of this kind due to the fact that the language has runtime security and a straightforward system call interface, as well as the code is compiled into static executable files that run quickly and work efficiently. However, you also need to worry about portability: while Go programs are easily portable, Go runtime is now intended only for a few important target platforms - and their number is much smaller than gcc and glibc are supported.

I am not aware of such projects.

tEoPS

Many books have been written on how to learn to program - but few of them talk about how to program well. Brian, your book “The Elements of Programming Style” is a real classic, but my students have trouble reading examples (they are in Fortran 66 and PL / I). Is there any hope of updating them, or is there perhaps some alternative book?

Kernigan : The languages ​​that Bill Plager and I used in The Elements of Programming Style are either dead (PL / 1) or have evolved (Fortran), so today the code in the book is really hard to read, even if the rules are good style is still valid. Bill and I wrote a version of a book for C at one time, but it’s not far off. One of the problems was that it was difficult for us to find examples for our rules. Another problem is that the real programs are much larger and more complicated than they once were, so finding and selecting code fragments that could be used in a similar book now is quite difficult. Thus, it is unlikely that this book will ever be updated.

Regarding other books, Josh Bloch and Scott Meyers have written excellent books, respectively, on how to write good code in Java and C ++. More generally, I always liked Steve McConnell's “Complete Code”, and I reread Fred Brooks’s Mythical Man-Month every year to look at him with fresh eyes. The list of books worth reading is not limited to this; Try to read the works about specific environments and programming languages.

Place C in today's world

As legend has it, the C language was created to develop operating systems. Over time, C ++ replaced it as an OS development tool for “large” platforms, leaving its predecessor with only niches of embedded systems (up to those that use 8-bit processors and cost 256 bytes of memory) and drivers in “large” systems . What decisions regarding design C seem reasonable to you today, and what would you change to adapt it for current tasks?

Kernighan : Consider - language C is the fruit of Dennis Richie's work; I claim that I just wrote a book with him. Dennis was a great writer - no worse than a programmer - so the book was created by our mutual efforts.

With all this, C is really still very popular for programming embedded systems and drivers, where efficiency and the ability to go down to the level of "hardware" are important. I think that an attempt to change C today would be a counter-productive solution, because one of the advantages of the language is that it is relatively stable. Seriously, I have suspicions (although I have nothing to confirm them) that, with the exception of small features like comments using //, most programmers use C as it was presented in the 1988 ISO standard; C99 and C11 standards do not change much in the programmer’s daily work.

Motivation for writing a book

I’m curious - why is there so another book about Go if so many books exist? How does “The Go Programming Language” differ from “Go Programming Blueprints” or “Go in Action”, with which it even has almost a table of contents? What is the meaning of another book - you want to have another “The C Programming Language”, but about Golang?

Kernigan : As it is said in Ecclesiastes, 12:12, “there will be no end to composing a lot of books”, which I kind of hint to you that your question about the need for another book is quite an old topic.

When someone writes a book, he always believes (or at least sincerely hopes) that he will succeed "better" than his predecessors - I mean not something negative, but the hope that organizing a new book , her examples, explanations and writing style will develop in such a way that readers will find this book useful. This is what Alan and I tried to achieve in the case of The Go Programming Language. If it turns out to be as useful as my book on C is great, but we will not aim at such a success.

I only looked at a couple of existing books about Go (and these were not the books that you listed), but in truth Alan and I deliberately decided not to read them - even the headlines were not watched as soon as we sat down to work on our own book , because we did not want to unconsciously borrow anything from other authors.

Donovan : For me, the motivation was to write such a book that I would like to read myself when I first started to learn Go - an exhaustive work that describes not only the language and its library, but also reveals the principles of language design, studies its advanced features, points to typical traps, and also reflects the style and aesthetics of the language itself.

Comparison with K & R suggests itself - I am not aware of another technical book that would be equally influential. It was not just a tutorial for the most important language of the “pre-Internet” generation, but also a reference to the language, and de facto its specification. Today, of course, The Go Tour, Godoc, and The Go Language Specification are at your service - all of which are available directly from your phone. Libraries have become more, utilities - more important. It turns out that the modern book on language had to focus on a very different thing - so we tried, how does all this fit together?