Elliott Stoneham @ElliotStoneham spoke about transpiling Go to other languages such as JavaScript, Java, and C++. See Elliott’s previous blog posts on GopherCon here:

Reflections on Russ Cox’s C-to-Go talk

Authored by sourcegraph

Guest post by Elliott Stoneham @ElliottStoneham. Elliott is author of TARDIS Go, a cross-language Go transpiler. Also check out his previous 2 guest posts during GopherCon on other Go runtime targets and running untrusted Go code as part of your application.

Here is our liveblog writeup of Russ Cox  @_rsc's talk yesterday at GopherCon.

I’ve spent the last few months championing the idea of “mutant”  Go-to-X transpilers, so Russ Cox’s C-to-Go talk was of particular interest to me.

Russ Cox spoke about the practical issues of source-to-source compilation when moving the existing Go compiler code, which is written in C, into Go. Which everyone reading these words will think is a wonderful idea.

Knowing the extent of the code you want to transpile has some significant advantages:

First, it gives you the fallback option of re-writing the source code itself in order to solve the problem, rather than forcing the translation code to deal with ever more unusual cases. A good example of this was Russ’ description of handing C goto statements.

Second, it allows you to know how source language features are actually used, and only code for those use-cases. Russ’ description of how to handle C union (by mapping it to Go struct) was a great example of this.

But for me, the real jewel in the crown is how type mismatches between C an Go are solved. Russ gave a great example of how the int type in C is actually a Go bool in some usage cases. The translation process therefore infers what Go type to use based on a variable’s usage pattern in the C code. Some of the techniques he described for working this out sounded positively magical.

Most impressive though, is that it is being done at all. A lesser programmer, like me, would have created a new type in Go that mimicked the operation of the C type to be replaced, and suffered the runtime overhead of that decision for a potentially very long time.

So a consummately professional job is going to be done on this C to Go conversion process. 

Russ himself is very clear that his code will not be a general purpose tool. Once complete however, I have no doubt that the Go community will take what Russ has done and seek to generalise it into an all-purpose C-to-Go transpiler, which will be an impressive tool to see.

So what lessons can we in the small “mutant” Go compiler community learn from Russ’ approach?

Firstly, it validates that source-to-source compilation is a viable approach, which is great news for those of us trying to convince the skeptical.

But secondly, and perhaps more importantly for the success of our projects, it demonstrates that compromises have to be made in the code of the source language in order successfully translate it into the target environment.

Take GopherJS (github.com/gopherjs/gopherjs) for example, it generates very fast JavaScript from Go, but currently does not permit goroutines or channels. Is that a price worth paying for a usable JavaScript implementation of most of Go?

Similarly, my own TARDIS Go (github.com/tardisgo/tardisgo) does not have very good support for the Go standard library. But it does give access to the cross-platform Haxe (haxe.org) standard library, which is available across all 7 target languages (JavaScript, Flash, PHP, C++, C#, Java and NekoVM). Is restricted access to the Go standard library a price worth paying for wide portability?

You can find the slides for my lightning talk on “mutant Go compilers” at 


Official repository for GopherCon 2014 talks and slides

Authored by sourcegraph

Check out the official repository for talks and slides from GopherCon: https://github.com/gophercon/2014-talks.

Andrew Gerrand: GopherCon 2014 closing keynote

Authored by sourcegraph

Andrew Gerrand @enneff joined Google and the Go team in Feb 2010. After joining, he had to rethink some of his preconceptions about programming from his prior work in Python, PHP, JavaScript, etc. He talked about what he has learned in his 4 years on the Go team as well as some general insights about programming.

(Ed. note: This was a fantastic talk that our note-taking wouldn’t do justice to, because it contained a lot of spoken insights, pithy bullets, and small code snippets. Also, it’s getting near dinnertime for your editors. We’ll link to the slides once they’re up.)

(Update: GopherCon talk slides are being posted here by speakers: https://github.com/gophercon/2014-talks)


Andrew gave demonstrations of all the ways in which interfaces are profound and core to Go.


Andrew’s first exposure to concurrency was in C, Java, and Python. Later, he encountered the event-driven concurrency model in Python and JavaScript. His initial reaction to Go’s concurrency model was, “Why can’t I wait on or kill a goroutine?”

He walked through the Go tour’s module on tree equality. http://tour.golang.org/#72

Why can’t Go code kill goroutines? Because that will encourage programmers to rely on thread-local storage. And that means that all code in the goroutine needs to be aware of which goroutine it’s in.

Andrew: “Concurrency is not just for writing faster code. It’s for writing better code.”

(Ed. note: Again, we recommend checking his slides, which have much more content, once they’re posted.)


Initially, Andrew thought Go’s syntax was confusing and inflexible. 

Error handing

Go makes error handling as important as your other code.


Packages are probably Andrew’s favorite feature of Go.


Godoc makes it easy to write documentation as you write code, and doing so makes your code better.


Andrew’s closing message: “Let’s build small, simple, and beautiful things together.”

Building Web Services in Go

Authored by sourcegraph

(Update: GopherCon talk slides are being posted here by speakers: https://github.com/gophercon/2014-talks)

Richard Crowley @rcrowley, of Slack, talks about building web services in Go.

Richard’s definition of a web service: “Data and a set of operations on that data networked using the http protocol; structured and machine-parseable requests and responses (otherwise, it’s more of a web application, not a service).”

Hello, www example


Pretty straightforward, but let’s zoom in on the handler function signature. It corresponds to this interface:

type Handler interface {
    ServeHTTP(ResponseWriter, *Request)

This is the lowest common denominator of a web service in Go. Embrace it, and use it as much as possible. Let’s rewrite “Hello, www” to use the interface.


JSON & Error handling

We want our web service to read and write JSON, and handle errors.


To parse and handle JSON, we can wrap the initial handler in another handler that handles the marshaling and unmarshaling of JSON to Go structs.

Go’s philosophy is that errors are not exceptional. You deal explicitly with errors. Error handling in the web service should be the same. The client should get as much information as possible.

You can make your JSON handler wrapper handle errors from the underlying handler and automatically marshal and unmarshal these errors into JSON. This way of handling errors conveys all the information to the web service client that you would see inside Go code.

Request multiplexing / build your own mux example

Now we want our web service to support (potentially very many) multiple API endpoints (request multiplexing). In Go, it’s all about wrapping/composing handlers (“handlers all the way up”).

Richard walks through building our own multiplexer (similar to the standard library’s request.ServeMux() handler).

You could do a linear scan through individual path handlers, but this is tedious and slow. It’s better to use a trie, so you can prefix match URLs quickly. You might also want to add wildcards.


How not to repeat yourself

In a given web service, there are some operations you want to do in many handlers (e.g., auth, rate limit checking). The solution, again, is to compose handlers.

You can implement middleware chains as a handler that calls a list of sub-handlers. The first handlers can handle rate limit checking, authorization enforcement. The last handler does the “actual work.” You can detect the first responder that writes a response (and therefore should prevent subsequent handlers from being called) by setting a written=true in the ResponseWriter header.



What we’ve covered so far is functionality. Now Richard talks about getting visibility into the status of our running service (e.g., logs and metrics).


Again, you can wrap your handler in another handler that automatically logs requests and responses to wherever we want. So the underlying handler is completely agnostic of logging.



Wrap the handler with something that records the time before running the underlying handler and records the finish time after it completes.

Who calls the first (parent) handler?

http.Server is what reads a raw request off the wire and passes it onto the top-level handler.

Gracefully stopping

Gracefully stopping a server is hard. There is a tradeoff between safety and liveness. You could wait an arbitrary amount of time for currently running handlers to complete or kill everything now and leave it in a potentially corrupt state. Neither is ideal.

In Go 1.3, there is more support for gracefully dying via the ConnState callback and SetKeepAlivesEnabled method.

Now, in server.Close(), the server will use these to signal to handlers that they need to die, and there is a grace period for this to happen.


Parting words

  • Embrace http.Handler interface as the fundamental building block
  • Provide abstractions within handlers, not as one giant handler to handle everything.
  • Compose bottom-up
  • Errors are not exceptional




Build Your Developer Tools in Go

Authored by Dennis Coldwell

(Update: GopherCon talk slides are being posted here by speakers: https://github.com/gophercon/2014-talks)

Alan Shreve (@inconshreveable) is the author of ngrok and gave us a breakdown on living outside the Cloud and building distributable production applications in Go. It’s a scary world out there when you leave the walled garden that is very much in your control with web-services. Alan’s talk focused on deploying to user-land and the challenges associated with these types of applications.


ngrok is a tool that runs on your laptop. A thought experiment to the audience: Imagine you have some software that you need to deploy 100/times a day, on wildly different platforms/hardware, and every deployment continues to run forever. This is a fundamental challenge, and very different from server deployment. Alan wanted to try to solve this problem using Go and make it easy to make quality software.

Embedding Assets

How do you embed all of your static assets (js/css/etc.) that you need for your program to run? In the server-space, you have full control and can ensure that the assets remain in the right place. Unfortunately, when dealing with end-users, you have to worry about them breaking things (for example, moving things on the filesystem).

Wouldn’t it be nice to have one deployment artifact? 

This is more than just a deployment nicety, it really makes it much easier to manage down the road. A helpful tool for this in Go is go-bindata. It’s a command-line tool that automatically generates source files with variables containing the raw bytes of files in a static assets folder. Also handles gzipping the contents for you!

Example usage:


Now, you can build with go build -tags “release”.


Simple answer, don’t do it. Just compile natively. Most practical solution is to automate using a VM tool like vagrant.

Why don’t we want to cross-compile? Answer: Cgo. More like Cno! Lot’s of problems like:

  • user.Current() doesn’t work when cross-compiling to Linux/Darwin
  • native resolver not used in cross-compiled builds, bgrok ignores resolve.conf

…but if you must cross-compile, gox is worth looking into.

 Terminal UX

Alan recommended checking out termbox-go. Its cross platform, pretty low-level, and totally awesome.

A specific pain point is dealing with windows. Users would just double-click the executable and expect it to install. They didn’t realize you need to run in it’s own terminal session.

To handle this, Alan built a tool called mousetrap that can capture mouse-events and detect a double click and raise a message to the user.

Tracking Crashes

Another problem is when your software crashes. When this happens server-side, you have lots of ways to track this. But when it happens on a users machine, there is no easy way to get this reported back. Alan wanted to be able to capture this information and be able to do something about it. 

Initially he tried a non-automated solution that asked users to drop the stack trace to a github issue. Guess how many people took advantage of this? Exactly one, which told Alan that ngrok NEVER CRASHES! 

Obviously people don’t want to manually report things. So Alan is looking to get auto-reporting built-in through an atexit() func. Alan is playing with the ast ast to wrap everything and auto-send when a crash occurs. Watch his twitter account to see how this pans out. The jury is still out.


How do you get new versions out to your users? Simple three-step process:

  1. Download new binary

  2. Move current binary to a different spot on the filesystem

  3. Move the downloaded binary into the old place.

Alan has created a library to help with this: go-update. Just updated today. New API changes out updating and checking into separate. Also has binary diffing and signature verification built-in.

Now that you have auto-updating, how do you know what URL to download from? Alan is working on equinox.io. A site which will handle a lot of this for you. Includes Stable vs. Beta vs. Custom release types. Has a REST API that allows you to POST up your releases. Definitely worth checking out!


Dennis Coldwell is an engineer at Junction and loves playing with shiny auto-updating things.

Building Database Applications with database/sql

Authored by sourcegraph

(Update: GopherCon talk slides are being posted here by speakers: https://github.com/gophercon/2014-talks)

Baron Schwartz @xaprb, CEO of VividCortex, shows us how to properly use Go’s database/sql package (using MySQL as an example).

An excellent tutorial here: http://go-database-sql.org/

Schwartz’s initial impression of the database/sql package was that it repeated some common mistakes in database connection interface libraries. But upon closer inspection, he changed his mind. [He shouts out to Brad Fitzpatrick for making the package so awesome.]

Basic concepts

  • Open() – creates a DB
  • Close() - closes the DB
  • Query()
  • QueryRow()
  • Exec()
  • Row - A row is not a hash map, but an abstraction of a cursor
  • Next()
  • Scan()

Note: a DB is not a connection. 

Some patterns and code snippets


He shows a simple, but complete, program that demonstrates all the basic concepts of how to properly use the database/sql package.
Note that at “// What do we have here?”, you do not have a connection to the database, because you haven’t done anything. database/sql creates and destroys connections for you underneath the hood.

A DB is not meant to be opened and closed at function boundaries. It should essentially be global and stick around for the entire duration of the program. Connection pooling is done for you under the hood.

QueryRow(“select …”) - Use this when you expect the query to return a max of 1 row from the database. A row is not a higher-level abstraction (e.g., hashmap) over the row. It is a cursor (which is more memory efficient, puts the power in your hands), so you need to use Scan().


Query(“select …”) - Don’t concat strings together to avoid SQL injection attacks. Be safe. Use ‘?’ parameters and let the driver prepare statements. Returns a Rows (rows set), again, not a blob of memory with arrays/hashes, etc. It’s just a cursor. Use rows.Next() and rows.Scan() to advance the cursor and scan the value out of the row and copy them into destination values (interfaces or pointers).


Afterward, remember to check for an error. Remember to close the Rows object (defer rows.Close()). Otherwise you will leak a database connection.


Explicit preparation of statements - the prepared statement in Go is NOT necessarily bound to a single database connection. If the connection used to prepare the statement is busy, the library will try to re-prepare the statement and use another connection. This is a little bit of magic.


Use stmt.Exec() for insert and delete, since they don’t return rows. If you use Query(), it will return a Rows (which you probably won’t close) and you will unnecessarily hog a connection until the Rows object is garbage collected.


Further advice and good-to-knows

Worth reading the documentation carefully (good, but dense; doesn’t repeat itself). E.g., there is a connection pool, so don’t do this yourself. And you can’t use uint64 with high bit set in parameters (#gotcha); this can bite you if you have auto-increment keys with on int64 column.

Don’t defer() in long-running functions. Memory usage will keep going up.
Don’t use cxn state. A lot of people have a habit of setting session variables before executing queries, but here, the operations you execute are not bound to a specific connection. Use Tx to bind to a connection (call db.Begin()).
And on that note, don’t do db.Exec(“BEGIN …”) or db.Exec(“COMMIT …”). Use db.Begin() and db.Commit().

db.Exec will retry a query 10 times if it fails. So if you have a bad query, you log into MySQL and kill the connection, it will rise from the dead 10 times.

There are some issues with leaking/not deallocating prepared statements.


Use provided Null types (e.g., NullString), because you can’t scan a null into a string.

You can create custom types using the built-in interfaces. Use case: transparently encrypt/compress data stored in db. So if, God forbid, someone executes a successful SQL injection, they won’t see anything useful.



Panel discussion with Go team members

Authored by sourcegraph

Blake Mizerany’s scheduled talk, “Little Known Tricks in the Go Standard” was made redundant by other talks, which covered all of Blake’s material. Instead, Blake hosted a panel discussion with 4 members of the Go team: Rob Pike, Andrew Gerrand, Brad Fitzpatrick, and Robert Griesemer.

(Ed. note: We’ve paraphrased most of the responses, and we’ve omitted the answers that referenced personal stories or jokes that wouldn’t come through in writing. Watch the video (which will be posted later) if you want to see the full Q&A. Let us know if we’ve missed or mistranscribed anything.)

Q: Rob (Pike), what was the most important thing you learned in C++ that affected Go?

A: Build time matters more than anything else. There are so many other things I could think about, but they’re all “what not to do.” The amount of extra typing you must do is awful. One afternoon, I typed the same function signature 56 times. 

Q: Robert (Griesemer), you worked on V8 before coming to the Go team. What have you brought to Go from that experience?

A: I worked mostly on the V8 internals. So, I wasn’t necessarily an expert on JavaScript, just as you can write the JVM without knowing Java. I also didn’t grow up with a C and Unix background, as the rest of the Go team did.

Q: What were the first Go programs you wrote that genuinely surprised you?

A from Andrew Gerrand: Probably the http.HandlerFunc type, which implements the http.Handler interface, but it’s a function type. When I first saw this, it was like “woah, that’s weird.”

A from Rob Pike: http.HandlerFunc was going to be my answer. Another thing was the encoding/xml package, where you just write the struct with tags and encoding/decoding just happens.

A from Brad Fitzpatrick: When there’s a named type that’s not a struct.

A from Robert Griesemer: When I realized you can have a non-nil interface that you assign a nil value to. (Brad Fitzpatrick agreed. Rob Pike: “nil is a value, too!”)

Q: What was the most awkward thing you’ve seen written in Go?

A from Andrew: Some of Brad Fitzpatrick’s tests. And bad concurrent code.

A from Robert: I still see a lot of “if boolVar == true”. And for loop index variables that have long names.

Q: What contribution you made to Go are you most proud of?

A from Brad: net/http. (Rob Pike: “I’d like to thank Brad for the net/http and os/exec packages. I think they’re just marvelous.”)

A from Andrew: map deletion syntax.

Q: What do you wish you hadn’t contributed to Go?

A from Rob: netchan. Also, variable declarations. They could be cleaner and less confusing.

A from Brad: C constants in the os package that are named like C, like os.O_RDONLY.

Q: The implementation of sync.Pool uses all kinds of stuff in the runtime that we don’t have access to (such as garbage collector internals). Why?

A from Rob: It’s the job of the stdlib to give you controlled, clean access to certain things. The behavior of the garbage collector is something that should probably be hidden from user code.

Q: What was awkward about var decls? [Referring to Rob’s statement above.]

A from Rob: Shadowing. Colon-equals syntax is good, but it looks like an assignment (not declaration). There are so many ways one can declare a variable. Also, you can’t declare the same things with “var” that you can with colon-equals, so it’s not clean. It all works pretty well in practice, but there are some corner cases that’d be nice to clean up.

Q: Are there any plans to make the garbage collection in Go pluggable?

A from Rob: It’s open source. If you make a patch to improve it, we’ll accept it. There are no plans to make it pluggable, but we’re always trying to make it better. Note that Go’s garbage collector doesn’t have a lot of flags (like Java’s garbage collector). That’s on purpose.

Q: Why are build tags in comments?

A from Andrew: Because they’re not part of the language, they’re part of the build system. The language is interpreted by 6g, and the comments are interpreted by the go tool.

Q: What is the next thing that Go can do to increase the rate of its growth?

A from Andrew: I’m really excited about Go moving into new spaces. Most people use Go to write servers now, but it’s exciting to see Go being used in the embedded (ARM) space, and Gustavo Niemeyer’s graphics stuff. Also, desktop apps, mobile apps. We want to help improve support in these areas in the coming years.

A from Robert Griesemer: I’m looking forward to a Go compiler written in Go. I think it could be much faster than it is now. (Rob Pike: “Yeah, Go builds are way too slow. [laughter] I mean it.”)

Q: What about Go 2.0?

A from Andrew: We have a label in the issue tracker for Go 2, and we use it to label issues that we can’t address yet. We’ll address those issues when the next breaking release comes along. We’re learning from how other languages have made breaking transitions, such as Python 2 to 3. Overall, Go 2 is not top of mind for us right now.

Q: You blogged about the unexpected uptake of Go in the dynamic languages community (as opposed to the C/C++ community). Does that change your plans for the language?

A from Rob: It hasn’t changed the language, but it has changed my own perception of the way you can use it, what’s important, serialization, etc. We had no idea that dynamic language people would adopt Go this much when we designed the language; it happened well after the initial design. Even if we knew about it in advance, I don’t think it would have changed the language design much.

Q: What’s the best thing about your open source contribution process?

A from Rob: Windows support was entirely from open source contributors. It’s a complete vindication of the open source ideas.

Q: Have you looked into embedding Go in C, Rust, etc.?

A from Rob: We’ve thought about it a lot and want it to be possible. The challenge is that Go’s runtime is built in such a way that it must own everything: memory, signals, etc. All of this is dictated by Go’s concurrency model and implementation. E.g., stack switch when switching between C and Go in cgo. Embedding is a tricky thing, but we really want to see it.

A from Robert Griesemer: Also, since we have a garbage collector, we need to track pointers on either side of the language fence.

Q: Brad, how did you design the HTTP keepalive pool?

A from Brad: Someone from the Chrome team wrote a long blog post about their HTTP keepalive support. I read this blog post and heard about the performance benefits they got from this. Adding it to Go took just a few lines, but the Chrome implementation required many more lines of code.

Q: If you could add one thing to the Go stdlib, what would it be?

A from Andrew: A superb, universally cross-platform graphics toolkit that looks amazing.

A from Rob: We have a lot of good tools for static analysis. I’d like to see a good tool for dynamic analysis. I haven’t seen any languages with the kind of tool I want.

A from Brad: Android, iOS, generics. [audience laughter]

A from Robert Griesemer: I’d like the compiler to be a library so I can call it and get an executable that I can invoke from code.

Q: What’s the best way to work around the lack of generics and polymetric polymorphism?

A from Rob: If it’s not performance critical, just use reflection. Otherwise, use Robert Griesemer’s fantastic libraries for source code rewriting, and write a tool to automate the writing of source code. The whole computing community underappreciates the value of programs that write programs. This is a perfect use for them.

Q: What are the plans for Go Oracle?

A from Robert Griesemer: This is really Alan’s work. My contribution is the go/types package, which is essentially complete but probably has some bugs. The first true implementation of this is in Go 1.3’s godoc, which has the Oracle’s functionality built in.

A from Andrew: A lot of people want autocomplete in editors. My main issue is navigating the code I’m working with, and understanding that code. Once I understand the libraries, remembering what to type is not the biggest issue. I’d love tools that help you understand how code fits together in a foreign codebase.

Q: How did interfaces and structural typing come to exist?

A from Rob: In the first or second day, we realized we wanted a pure behavioral type, so you don’t conflate the data and methods.

A from Robert Griesemer: We debated for a while whether you should be able to have concrete methods on an interface. We concluded that not having concrete methods would keep the concept of interfaces orthogonal from the other concepts in the language.

Q: What is your favorite Go keyword?

A from Andrew: notwithstanding

A from Rob: go

A from Brad: defer

A from Robert Griesemer: go

Q: What is your least favorite Go keyword?

A from Andrew: thetruthofthematter

A from Rob: fallthrough

A from Brad: fallthrough

A from Robert Griesemer: goto

(Ed. note: Don’t believe that notwithstanding and thetruthofthematter are real Go keywords? We didn’t, at first. grep the Go source to prove it for yourself.)

Gobot: Go-powered robots

Authored by sourcegraph

(Update: GopherCon talk slides are being posted here by speakers: https://github.com/gophercon/2014-talks)

Adrian Zankich and Ron Evans, members of the Hybrid Group and creators of KidsRuby, talk about Gobot, a library for programming robots in Go.

Ron leads with a quote from the Go FAQ, “By its design, Go proposes an approach for the construction of system software on multicore machines.” He then follows immediately with a quote from William Gibson: “The street finds its own uses for things.” Thus Go for robots.

Gobot uses the adapter pattern. Devices have drivers (go packages). Pub/sub system to communicate events from devices to robots (in code, you call goBot.on(<event>, <handler func>)).


API calls are routed through what they call the “Master Control Program” or MCP.


Gobot supports test-driven robotics (If you’re designing, for instance, a sprinkler system that only goes off once a week).

Gobot-related libraries

There’s a command-line interface (gort.io), because you don’t want to use a GUI to configure hardware.

RobotOps is DevOps for robots (robotops.com)

Demo: Gobot and Arduino

There is a Gobot adapter package for Arduino. Ron shows a code example, which is quite simple. Gobot uses firmata, a protocol for communicating with microcontrollers from a host machine (there’s a simple Go package that encapsulates this). The code is simple and clean – they create a firmata connection to a device and send messages over pins. The device in this case is an LED connected to the Arduino.


Demo: Gobot and Beaglebone Black

There’s an adapter for Beaglebone Black, a single board on-chip ARM Linux computer. Much pins, such I/O. The code uses the same device drivers with a different adapter (Beaglebone instead of Arduino). This involves just swapping out the Beaglebone adapater package for that of the Arduino. They do the same demo with the LED now plugged into the Beaglebone.

In the Arduino, the PC was running code and remotely issuing instructions to Arduino. With Beaglebone, code is running on Beaglebone on its onboard chip. The code hasn’t really changed, except for the adapter.

Robeaux.io is a web app (built with AngularJS) that allows you to issue input to your program, controlling the robot from your browser. [Adrian demos strobing the LED by clicking on an HTML button.]

[Free stuff giveaway interlude. Much tweeting ensues.]

Demo: Conway’s game of life… with Robots (Spheros).

Rules of Conway’s game of life here: http://en.wikipedia.org/wiki/Conway’s_Game_of_Life.



With physical robots, they approximate the number of neighbors of a cell (i.e., Sphero) by taking the inverse Fourier transform of the approximate frequency of collisions.

The Gobot “application” code for this demo is about 100 lines long.

Demo: AR Drone + Digispark

Digispark is one of the smallest microcontrollers. Digispark is plugged into AR Drone via USB. They have 2 Gobot instances, one running on a laptop communicating with Digispark (to toggle the LED) and one running on the computer inside the drone itself (to fly the drone).


Demo: AR Drone + OpenCV

OpenCV is a powerful open-source computer vision library. Gobot has a Go wrapper library around OpenCV. The code loads training data to train a face detector. They hook up a Drone camera to OpenCV and laptop screen. The drone flies up to face level, hovers, runs face detection. Code is less than 100 lines long. Very slick.

Demo: AR Drone, Neurosky, OpenCV, PS3 Controller

The code, again, is not much more than 100 lines of code. They use Gobot to fly the drone while observing Adrian’s (the pilot) brain state as a histogram of brain wave types.



The site is Gobot.io. Gobot is all open source, Apache 2.0 license.

Corrections: The original version of this post misstated Ron’s name as “Rob” (perhaps short for “Robot”?) and incorrectly stated that Robeaux.io is a NodeJS app.

Running untrusted Go code as part of your application, an outline idea

Authored by sourcegraph

Guest post by Elliott Stoneham @ElliottStoneham. Also check out his guest post from yesterday on other Go runtime targets.

I’m writing this blog entry as a reflection on the first day of GopherCon.

One of the great strengths of Go is the ease with which one can reference and use an existing package created by a third party, often on an open-source basis.

But there are inherent risks with this. The version and change control issues are well understood, with a number of approaches to managing them evolving, for example vending. However the security issues have been less well discussed.

When your application uses a third-party Go package, you currently give that software author unrestricted access to all of your data and systems. There are tremendous opportunities for badly written or malicious code to be unwittingly included inside production systems.

What we need, I think, is to implement security controls on un-trusted Go packages.

Luckily, as Rob Pike said at GopherCon yesterday, the package location string could contain additional elements besides the package URL. So some top-level trust-control instructions could sit here. Trust control should certainly be part of the programming code, rather than an external addition. So for example one might write:

import “github.com/coolhacker/usefulrepo,trust=none”

As with using Go on AppEngine at the moment, trust controls that might be implemented include access to:

  • multiple CPUs;
  • the network;
  • the filesystem; and
  • other packages.

I would expect the untrusted Go code to have no visibility of the trusted code’s namespace. 

Clearly rules also need to be put in place to match the named types at the trusted and untrusted code boundary.

There are two approaches to implementation, depending on the execution needs of the third-party package.

If the third-party package, or a package it relies on, needs to use standard package “unsafe” there is really no alternative but to use a separate execution space for that code, where there is no possibility of it accessing the main application’s memory space. 

But if, like code for use on Go App Engine, the third-party package does not use standard package “unsafe” an alternative is available. 

Automated code refactoring can be used to generate a trusted version of the un-trusted code, that can then be called using the normal Go approach. 

I know this can be done, because my mutant Go compiler, TARDIS Go, already does something very similar, only it currently emits Haxe rather than Go.

So I want to see a new tool emerge which would vendor third party packages, but with the addition of security controls added through automated code refactoring. 

Is anyone else interested in working on this? 

Catch me at GopherCon on the Hack Day, where I’ll be speaking, or @ElliottStoneham.

Posted by Elliott Stoneham @ElliottStoneham.

Elliott started programming in 1974, he exhibited at the first Internet World Show in London and wrote the website that sold the first insurance product online in the UK. After working as a systems programmer into his 30s, Elliott spent two decades in IT and general management. Outside of IT, he has two master’s degrees in business administration and Chinese (普通话). He is also holds qualifications in computing, coaching, finance and teaching. But recently he has been tempted back to his programming roots by the elegant Go language. His current personal mission is to write a Go compiler targeting the amazing Haxe language. Professionally, he is a freelance Go developer. He currently works for Countersoft, helping to develop their new Documize product.