Interviews: Alan Donovan and Brian Kernighan Answer Your Questions (slashdot.org) 42
A few weeks ago you had the chance to ask Alan Donovan and Brian Kernighan about programming and their upcoming book, The Go Programming Language (available as an eBook Friday the 20th). Below you'll find their answers to your questions.
Donovan/Kernighan: Thanks to all the Slashdot readers who posed such thoughtful and provoking questions; we’re sorry that space limitations prevent us from answering more of them. Neither of us is part of the core Go team, so we can’t give authoritative answers for some of the questions that deal with future plans for the language or tools.OpenGL and LockOSThread
by Anonymous Coward
Hi, I've stopped using Go when I saw the hacky stuff I need to do to get libraries like OpenGL to behave correctly. Are there any plans to fix this?
Donovan: The crux of the problem is that many C libraries such as OpenGL implicitly use the identity of the calling thread to store context information. In some cases, this is because the API was designed before multithreading was the norm, when global variables could be safely used to store context information. In other cases, this design is merely a matter of convenience, since it saves passing an extra parameter to every call.
The designers of Go rejected thread-local storage (TLS) because of its tendency to cause "action at a distance": it makes programs slightly shorter but much harder to read. (See p.282 of our book.) Since the lack of TLS in Go is considered a feature, there are no plans to "fix" it, but it may be possible to make TLS-heavy C libraries work better with Go. My colleague David Crawshaw just gave a talk at DotGo 2015 in Paris about this very issue as it concerns OpenGL.
Why was package versioning left out?
by genocitizen
Why was package versioning left out? And are you guys still fond of this decision? As I use Go more and more I see this to be the weak spot; software has been around for many decades, and we all know that it is continuous evolution. Go's import system does not allow specifying or hinting a version, nor does the `go get` command (although it supports major VCSes), and that's how hacks like gopkg.in have been conceived. And it's not like package managers for other languages haven't already solved in a more or less elegant way the problem already...
Donovan: Go is designed for large programs, and versioning is notoriously hard in that context. About ten years ago, there was an experiment to introduce versioning into Google's build system (which was designed by Rob Pike and others). It failed because of the "diamond dependency" problem, which I'm sure many of you have heard of---it's the classic problem of version numbering. Consider 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 the author of B decides that only version 1 of D will do, and the author of C requires at least version 2 of D, you have an impossible set of constraints. If you're lucky, you might be able to build A with both the old and the new versions of D, but in general this doesn't work. Since that experiment, Google hasn't touched automated versioning again. The way we do versioning is simple but manual: we treat each version of a package as a separate entity with a distinct name (for example, "D1", "D2"), and work hard to limit the number of versions of each package---ideally to one. That’s why versioning hasn’t been a priority for us at Google. However, this August, the prolific Dave Cheney proposed a scheme for Go package version numbering, so perhaps we’ll see development of this idea in the near future.
Error Handling in Go
by JPyObjC Dude
Go language differs from many other languages in how it handles Errors. Can you summarize the benefits and drawbacks to the Go language error handling approach when compared to Java for large scale applications.
Kernighan: In general, Go strongly encourages being explicit about errors. The standard library functions almost all return an error status along with the function value and your code must do something with that error status; you can’t just ignore errors. In this respect, Go is similar to Java, where you have to either catch or throw errors; you can't just do nothing. This is a nuisance in small one-off programs, but it's a life-saver in larger ones. So both languages are doing "the right thing".
Where they differ is primarily in the use of exceptions. Go does not have an exception mechanism, so there's no direct way to handle all the errors in a single block as there is with Java's try/catch, though the defer statement can help to consolidate error handling. This means that Java code might be somewhat more compact (in this respect only!), but perhaps at the price of not providing as much precise information about what went wrong.
Our Go book spends quite a bit of time on the topic of error handling, and in most of the examples we've tried to show how to deal with errors properly rather than ignoring them, even though this can make the example programs a bit longer.
Donovan: I’ve written a fair amount of Java code and, in my experience, good error handling is about equally hard in both languages. However, Go reduces the syntactic cost of augmenting an error message as you propagate it, because you have to write more or less the same code whether or not you augment the error with new information. Java, by contrast, makes it so tempting to avoid writing try/catch/throw blocks that, too often, programmers propagate exceptions without thinking. It’s interesting that you can never divine such subtle pragmatic differences between languages merely from reading their specs.
Usage
by Behrooz Amoozad
For what scenarios and projects do You recommend it and for which you recommend against using Go?
Kernighan: Go is a very good general purpose language, and we would have no hesitation about using it for any new task. It seems especially well-suited for programs that involve networking or other concurrent tasks; goroutines are very convenient and efficient, and there is also good support for more traditional shared-memory approaches. Empirically, people who write new networking code tend to like Go. I personally would use it for anything where in the past I might have used C or Java or C++.
Go has also gotten some traction as a scripting language, a potential replacement for large Python scripts. This may seem a bit surprising, since scripting languages are very convenient for cobbling something together in a hurry. The problems come later, when the cobbled-together code starts to crash with type errors or other faults that could have been detected much earlier with a statically typed language. Go won't replace Awk for one-liners, nor is it likely to replace Python or Perl or Ruby for 10- or even 100-line programs, but after a while, the combination of type safety and efficiency is worth the somewhat higher up-front cost.
Why should I use Go?
by aaaaaaargh!
For someone like me who likes garbage collection, multiple dispatch, and extreme abstraction capabilities in high level languages like Common Lisp, and safety, compile-time error detection, readability, and speed in low level languages like Ada or Haskell, what are the benefits of using Go in comparison to these two different types of languages? What new useful features does Go bring?
Kernighan: Ada and (especially) Haskell don't seem like low-level languages and Haskell is inscrutable to newcomers, but those are quibbles. Go has everything you mention in both of your lists of desirable attributes (depending perhaps on what you mean by "extreme abstraction"), but it also provides concurrency in a convenient and efficient form; that's a big win for some kinds of applications.
Donovan: Go seems very plain when compared with languages like Common Lisp, C++, Java, or Python. It has no macros, no templates, no classloaders, no metaclasses. Features such as these are often the first things I, being a PL geek, rush to play with when writing toy programs in a new language, but they are not usually the things that matter the most when programming in the large. I can recall without fondness many days spent debugging overly clever uses of the C++ STL or non-hygienic Lisp macros or the Python __call__ method. The design of Go recognizes that simplicity, homogeneity, and familiarity of a large code base are more valuable to the team as a whole than the benefits to each individual of using their favorite (obscure) language features for each task.
Go’s potential
by Qbertino
What serious long-term real-world potential do you see for Go? How do you see the potential of Go replacing existing open source webstacks such as Apache and PHP, Python or Ruby? Was Go built with a technology update of existing approaches in mind? How feasible is it in your opinion to try and replace the existing complex stacks with pure Go runtimes?
Kernighan: The reason it took God only six days to create the universe is that he didn't have to deal with the embedded base. Realistically, no programming language is likely to completely replace major existing code bases; it's just too much work. Go is often a good choice for new projects or where one is planning to rewrite an existing system anyway, and it can provide a good interface to existing code through foreign function interfaces, particularly to C libraries. But wholesale replacements seem unlikely.
Donovan: I agree with Brian that Go isn’t likely to eliminate any other language or library, but that is not its goal. Go provides an attractive alternative. A good part of Go’s popularity comes from the ease with which you can build useful web servers and other distributed systems using little more than the components of the standard library. The library was produced recently, and thus with the benefit of hindsight, by systems experts, and it often makes third-party servers like Apache or frameworks like Rails unnecessary for the first steps---although of course similar frameworks do exist for Go too.
Official Go IDE?
by Qbertino
Is there an official cross-platform Go IDE in the works? Experience shows that adoption is accelerated by offering a solid toolkit that is easy to pick up and get started with - such as the formidable Android Studio IDE Google offers to developers. Are there any plans similar to this for Go? I would like to see it take the place of C++ in the development of performant end-user applications with GUIs - are there any officially sanctioned projects that aim to provide a serious GUI toolkit and stack based on Go?
Donovan: We agree that good IDE support is important for attracting new users to Go, though my colleagues and I came to this realization rather slowly as, perhaps unsurprisingly, most of us use very traditional editors like Vim, Emacs, SublimeText, and even Acme, which are not what most people think of as IDEs. This year, JetBrains have created a team to develop a Go plugin for IntelliJ so that IntelliJ IDEA users can build, test, debug, and refactor programs written in Go as easily as in any other language.
As for cross-platform GUI toolkits, there’s no canonical solution yet, though there have been some interesting experiments such as GXUI and Shiny.
Should Go replace Java?
by Martinjnh
Should Go replace Java as development platform/language for android?
Donovan: The Go team at Google is working hard to make it possible to use Go to write mobile applications on Android and iOS; see Hana Kim's GopherCon 2015 talk, for example. But for now this is just an experiment and, as Brian wrote above, it's not Go's goal to replace major existing code bases.
Safe Performance
by snadrus
Reimplementing the Gnu+Linux toolchain in GoLang could provide safety that decades of eyes on C could not (thinking about the recent BASH bugs & OpenSSL overruns). Even a small portion would add security to Android. Performance is close & 1.5's library loading should keep executables light. Is there interest in rebuilding Linux's base userland?
Donovan: Go is a good fit for these kinds of tools because the language has good runtime safety and a straightforward system call interface, and it compiles to static executables that start quickly and run efficiently. Portability might be a concern: while Go programs themselves are highly portable, Go's runtime currently targets only a handful of major architectures, far fewer than gcc and glibc support. I'm not aware of any rebuilding projects.
tEoPS
by M. D. Nahas
There many books on "how to program" but few on "how to program well". Brian, your book "The Elements of Programming Style" is a wonderful and a classic, but my students have a hard time reading the examples (Fortran 66 and PL/I). Is there any hope for an update? Is there any similar modern-language book that you recommend?
Michael Nahas (son of Joe Nahas)
P.S. I totally stole as much as I could from you when writing my tutorial for the language Coq. Sorry/Thanks!
Kernighan: The languages that Bill Plauger and I used in "The Elements of Programming Style" are either long gone (PL/1) or very much evolved (Fortran), so the code is indeed hard to read today, though most of the rules of good style are still valid. Bill and I once started a version in C but didn't get very far. One problem was that the original book relied almost exclusively on code fragments from textbooks. Modern textbooks are far better than they were 40 years ago; most code is syntactically correct and mostly works. So it was hard for us to find textbook examples to illustrate our rules. Another problem is that real programs are a lot bigger and more complicated than they were, and it's hard to find excerpts that would work in a book. So an update of EOPS isn't likely, much as it would be nice to have one.
As to other books, Josh Bloch and Scott Meyers have written excellent books on how to write good Java and C++ respectively. More broadly, I have always liked Steve McConnell's "Code Complete", and I take a fresh look at Fred Brooks's classic "The Mythical Man Month" every few years. There are plenty of other books about how to program well in various languages and environments; it's well worth reading some of them to see how other authors approach the topic.
C's current place in the world
by MountainLogic
As the legend has it, C was created to support operating system development. As time has gone by C++ has slipped into OS development on larger platforms. It seems that much of the current core use of mother C is centering on embedded processors (all the way down to 8 bit micros with 256 bytes of RAM) and drivers in larger systems. For current use what design choices in C do you see as wise and what would you change given the current usage of C. (P.S. Thank you for co-authoring the most wonderful, perfect, clear and concise technology document ever.)
Kernighan: Bear in mind that C is Dennis Ritchie's work; I can only claim to have written a book with him. Dennis was a great writer as well as a great programmer and language designer, and the book was very much a joint effort.
That said, C is indeed still popular for embedded systems and drivers, where efficiency and the ability to get right down to the hardware matters. I think that changing C today would be counter-productive; one of C's strengths is that it is quite stable. Indeed, I suspect (though without having data to prove it) that except for minor features like // comments most programmers use C as it was after the 1988 ISO standard; the C99 and C11 standards did not change much of programming practice.
Motivation for writing the book
by jameshwang
I was curious out of all the Golang books that currently exists, how does this book, "The Go Programming Language," differ from the rest and fit into the landscape of Golang? I've read some of the other books like "Go Programming Blueprints" and "Go in Action." Specifically with "Go in Action," the table of contents seems similar to your book.
I guess what was your motivation to write this book and how will it be different from all the rest? Brian, are you hoping this book becomes what "The C Programming Language" became but for Golang?
Kernighan: As it says in Ecclesiastes 12:12, "of making many books there is no end", which suggests that your question about whether another book is needed is an old one.
When one writes a book, there is always the belief or at least hope that one can do it "better" than others, not in any negative sense but just that new organization, examples, explanations, and writing will all combine in a way that readers will find helpful. Certainly that has been what Alan and I have tried to achieve with "The Go Programming Language". It would of course be wonderful if the Go book was as helpful to programmers as the C book seems to have been.
I have looked at only a couple of the many Go books that have already been written (and not the ones you mention), and in fact Alan and I quite consciously stopped even looking at titles once we started thinking about our own book, since we didn't want to inadvertently borrow from other authors.
Donovan: For me, one motivation was to write the book I wished I had been able to read when I started learning Go---a comprehensive book that covers not just the language and its library, but one that motivates the design choices, explores advanced features, flags the pitfalls, and conveys the style and aesthetics of the language.
Although comparisons with K&R are inevitable (and flattering), I don't think any technical book can ever be as influential as that one. It was not just a tutorial for the most important language of a (pre-Internet) generation, but also its reference manual and de facto spec. Today, of course, you can browse The Go Tour, Godoc, and The Go Language Specification from your cellphone. Libraries are larger and tooling is more important. A modern book must have a different emphasis. We've tried to show how all the parts fit together.
Re: (Score:1)
That may be because he doesn't create programming languages?
Re:Useless (Score:4, Informative)
Pink is a very masculine color. Or at least it used to be, prior to a few decades ago when somehow things got swapped around. People used to dress their little boy babies in pink, and their little girl babies in blue. Pink, being a shade of red, reflects strong emotion, whereas blue as everyone knows reflects calmness and tranquility (and sadness).
Re: (Score:2, Funny)
Why do people like you continue to call things "masculine" or "feminine"? You keep reinforcing gender sterotypes. It is that kind of toxic behavior that keeps me from programming in Go. So stop your microaggressions.
Re: Useless (Score:1)
Boycott? Why not Girlcoot, you sexism bastard?!?
"of making many books there is no end" (Score:4, Funny)
how do you keep them standing then?
Re: (Score:2)
That's easy: book n leans against book n+1. If you had only a finite number m of books on a straight shelf, then that last book, having nothing to lean against, would topple, and then book m-1 would have nothing to lean on either and thus topple, and so on down the chain back to the first book. With an infinite shelf you don't have that problem.
Re: (Score:2)
I suffer this problem have having books topple. Where would I find an infinite shelf? Is that something they sell at Ikea?
You'll probably find it somewhere on here, which is my new favourite web page:
http://bookshelfporn.com/ [bookshelfporn.com]
Thank me later.
Re: (Score:2)
No, they don't sell one at Ikea, but you might be able to find one at Borges' Library Furniture and Supplies [wikipedia.org].
Please be advised that if you put your current (finite) book collection on the shelf, or if you acquire an infinite collection and put it on the shelf in a way that leaves some space unoccupied, your books may topple. You need to acquire an infinite collection and fill all the space on the shelf. But don't worry - even if your shelf is full it can always accommodate an infinite number of additional b [wikipedia.org]
Re: (Score:2)
Thanks (Score:2)
Re: (Score:1)
The people who cared about this kind of technical stuff left this site long ago. Good luck with your moderation though.
Re: (Score:1)
Where did they go?
Most of us have gone over to Hacker News (https://news.ycombinator.com).
Re: (Score:2)
Well, I messed up with counting Haskell among low-level languages (I was thinking "low-level=functional purity" in this case). Fair to complain about that. But Ada is definitely low-level, and also faster than Go, has multi-tasking built in since '95, and was designed for large projects, so I'm still kind of dissatisfied with their answer. I gave Go a try several times, but it didn't look as if it had anything that I couldn't get as easily with Ada or Scheme.
From a modern language I'd expect the deficiencie
Re: (Score:2)
Learn a lesson from C++: if you throw in everything and the kitchen sink then every programmer will know a different proper subset of the language, and maintenance will be a bitch.
Go Puns.... (Score:1)
Ready? Set? GO!
No! Don't Go!
Once you C, you will never Go back.
One for the money, Two for the show, three to get ready and four to Go.
I don't wan to Go... Well, I'll Go! I Must Go. I go where ever I want!
Make it, Go!
Go Go Google Gopher Gadget!
That's a no Go Zone...
Oh Look! Go Go boots!
Go in peace..
Let it Go... Let it Go....
Always learn as you Go..
Never Go out on a limb. Don't Go overboard either....
Go, God, Gold and Golf all start the same way...
Will she stay, or will she Go!?
Don't worry, not
Re: Go Puns.... (Score:1)
Re:Questionable name (Score:4, Informative)
The trick is to use golang as your search term instead of go.
Re: (Score:2)
Not in the first several pages of google results, there aren't.
Missing the point about TLS as used in OpenGL (Score:4, Informative)
Donovan is incorrect about the original reasons for use of thread-local storage (TLS) in OpenGL. The issue was performance. If you pass a context as an argument on every call, the library (and the device drivers, and ultimately the hardware) need to be prepared to validate and potentially change unbounded amounts of state information on every call. This imposes a significant cost on every call, even in the normal case where the context doesn't change. On the other hand, making the context thread-local means that the validation and state-change cost can be handled only when needed, as the result of an explicit call to change the current context.
Keep in mind that the original design for OpenGL paid a great deal of attention to fine-grained parallelism between the CPU and the graphics pipe. (Heavy use of batching in previous systems led to poor performance, because the graphics pipe would idle while the CPU built the next batch of commands, or the CPU was blocked while the graphics pipe dealt with a batch that took longer than average to render.) This meant that calls to transfer data were frequent and needed to have very low overhead. With hardware support, as on the SGI machines of the era, this was a very effective approach.
Current systems minimize data transfer as much as possible, so the design tradeoffs are different. Whether that helps make an argument for or against TLS in Go is something I've never looked into.
Re: (Score:3)
"They only need to be prepared to change state information if the context pointer changes." How do you know when the context pointer changes? Assuming a context pointer is passed on each API call, what do you compare it to in order to detect the change? Either a thread-local copy of the previous pointer (in which case you're still using thread-local storage, and you might as well keep enough thread-local state to avoid the comparison), or an identifier maintained by the hardware (in which case you've incu
Re: (Score:1)
Is there something wrong with LiteIDE? (Score:3)
Once again a question is asked about a golang IDE and LiteIDE is not mentioned. I personally think it rocks for go dev work.
https://github.com/visualfc/liteide