Slashdot Mirror


Interviews: Ask Alan Donovan and Brian Kernighan About Programming and Go

Alan Donovan is a member of Google’s Go team in New York and holds computer science degrees from Cambridge and MIT. Since 2005, he has worked at Google on infrastructure projects and was the co-designer of its proprietary build system, Blaze. Brian Kernighan is a professor in the Computer Science Department at Princeton University. He was a member of technical staff in the Computing Science Research Center at Bell Labs, where he worked on languages and tools for Unix. He is the co-author of several books, including The C Programming Language, and The Practice of Programming. Recently, the pair have co-authored a soon to be released book titled The Go Programming Language. Alan and Brian have agreed to give us some of their time to answer any questions you may have about the upcoming book, Go, and programming in general. Ask as many questions as you'd like, but please keep them to one per post.

10 of 185 comments (clear)

  1. OpenGL and LockOSThread by Anonymous Coward · · Score: 5

    Hi, I've stopped using Go when I saw the hacky stuff I need to do to get libraries like OpenGL to behave correctly. (see https://github.com/golang/go/wiki/LockOSThread) Are there any plans to fix this?

  2. Wisdom of naming it "Go" by ZeroPly · · Score: 5, Insightful

    There's already a game called Go, which has about a gazillion articles on how to program it. Couldn't you come up with a name that would be less ambiguous? Now, when you see a user group for "Go programming", you have no clue which one it is.

    --
    Support microSD: in a post 9/11 world, it is unwise to carry your data on media that you cannot comfortably swallow.
  3. Why the hell would anyone use Go? by xxxJonBoyxxx · · Score: 5, Insightful

    Why the hell would anyone use Go?

    (Serious question, since our editors didn't tell us why Go was created, what Go's intended purpose was and whether or not anyone is actually using Go.)

  4. Why was package versioning left out? by genocitizen · · Score: 5

    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...

    1. Re:Why was package versioning left out? by ewhac · · Score: 4, Insightful
      Because package versioning is not a language issue. It's a build issue, and should be part of your build system.

      "But go get ... reaches out and..." Stop. go get isn't part of the Go langauge; it's the default Go build environment. And yes, it lacks many features you'd want in a so-called "professional" build system (whatever that means this week).

      I get the impression that Go was perhaps intended to be used with repo, a tool principally used for managing the Android project, but also used elsewhere inside Google to manage large numbers of independent Git repositories. With repo, you establish a common branch or tag name across all the repositories that comprise your project, then "repo sync" to them. Poof! Build and version management. (Sorta.)

  5. Error Handling in Go by JPyObjC+Dude · · Score: 5, Interesting

    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.

  6. Gos potential by Qbertino · · Score: 4, Insightful

    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?

    --
    We suffer more in our imagination than in reality. - Seneca
  7. Official Go IDE? by Qbertino · · Score: 5, Insightful

    Is there an official cross-plattform 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?

    --
    We suffer more in our imagination than in reality. - Seneca
  8. Re:I worry about autonomous language activities by bobbied · · Score: 4, Informative

    Java is LICENSED by Oracle who doesn't give out the source code... Go is BSD licensed and has source code so you can build your own copy.

    Check with Oracle about the terms they use if you want to distribute their Java Virtual Machine in a commercial product. I can assure you it involves you providing them with cash before they will let you even distribute Java, unmodified, as part of your product. I know this from experience. I'll warn you, Java from Oracle does NOT come cheap if you wish to distribute it. Sure they will let you and your customer download it for free, but they want their cut if you download and distribute Java to a customer.

    With Go, there will be no such restriction. You can build and distribute Go to your hearts content w/o paying anybody even if you charge for it. You can embed Go in a project, modify it and sell it without having to give up your source code (as I read the license) as long as you leave the BSD license alone.

    --
    "File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
  9. Go objects by StealthyRoid · · Score: 4, Interesting

    I'm curious as to the design decisions that led to the way that Go objects are implemented, which feel and seem to operate like C structs w/ function pointers. Yes, all objects are essentially structs with function pointers, but most languages provide a good deal of syntactic and functional candy on top of them to make them more useful. With Go objects, you get sortof-inheritance, sortof-polymorphism, and sortof-encapsulation, which requires re-thinking a lot of design patterns that people learn working with languages like C++, Java, and even PHP. That's not necessarily a bad thing, I can see arguments for forcing people to get out of their comfortable patterns, I'd just like to know why.