One of the more common bugs that Go programmers write involves shadowing an error variable, as in the following code (taken from this relevant blog post):

var err error
if isSecure {
	config, err := GetTLSConfig()
	if err != nil {
		return err
	conn, err = tls.Dial("tcp", server + ":443", &config) // BUG
} else {
	conn, err = net.Dial("tcp", server)
if err != nil {
	return err
// use conn...

The intention of the line marked // BUG is to assign to the outermost declared err. However, the err declared in the if-block shadows the outer err, rendering the assignment useless. An error returned from tls.Dial will never reach the final if err != nil check. Not good.

I have on multiple occasions seen people bitten by this type of bug, but it wasn’t until a week ago that I realized that the compiler’s failure to detect it was probably unintentional. Go is kind enough to tell us when we declare but do not use a variable but, strangely, it doesn’t say anything about assigned and thereafter unused variables, which is our situation above.

I pointed out this omission in Issue #10989; and Robert Griesemer, while agreeing that it would be good to flag such “assigned and not used” errors, confirmed my suspicion that it would constitute a backwards-incompatible language change, and thus probably not find its way into the compilers.

Nevertheless, I had a hunch that it would highlight only buggy code, which might justify breaking such code. I decided to investigate. The convenience of the Go standard library’s go/ast package enabled me to quickly whip together a tool that approximates the desired behavior.

The implementation was fairly straightforward. I won’t go into details; the essential observations are of the scopes in which variables are declared and used, especially regarding loops, and of whether a variable can escape (by taking its address or being referenced in a function literal (closure)) and possibly be assigned later. I would later find that Alan Donovan had given a good lowdown of the problem when a nearly identical issue was filed a year and a half ago.

Running my tool against the standard library and a few packages in my GOPATH flagged 72 “assigned and not used” errors. A perusal revealed most of them to be innocuous (but sloppy) code, and 7 of them to be real errors. Not enough to justify a breaking language change, I thought. But when I posted my findings on the Go mailing list, Rob Pike made it clear that he thought the compiler should do this check.

We shall see. But honestly, I don’t see how this could happen without flagrantly violating the Go 1 Compatibility Guarantee.

In the past years I have been speaking at a variety of events, meetups and conferences, but for a JavaScript focused developer there’s only one mother of all conferences: Originally started in 2009, a time before node.js was released, and where jQuery was the hottest library; it has grown to be the de-facto conference for everyone in the JS world, with sister conferences all over the world. In 2014 I already had the wonderful opportunity to speak at JSConf EU (video) and JSConf.Asia (video), and this year I was invited to complete the trio and speak at the 2015 edition of in Amelia Island, Florida!

Continue reading »

Getting started with WebRTC on iOS

Hangouts does it. Facebook Messenger does it. We at do it. We all use WebRTC for client to client video conversations in our iOS apps, and so can you!

Introduction to WebRTC on Android

In this blog post we will investigate how you can get started with building WebRTC into your Android apps, using the native libraries provided by the WebRTC Initiative.

As described in Firefox OS as an IoT platform, we are re-using existing phone hardware to build Gonzo, our wireless camera. While this has some major benefits, like more mature software and a cheaper pricepoint, it also has a major downside: because a phone motherboard is not meant to be an IoT board it doesn’t offer any extensibility points.

A standard IoT dev board like the Raspberry Pi or Arduino comes with a number of General Purpose Input/Output (GPIO) pins. As a hardware developer you can use these pins to add new functionality to your board. For example, you can add new sensors to the board. For Gonzo we ran into the issue that we would like to add a LED light to the device, but the phone mainboard we use does not have GPIO ports.

But we’re creative thinkers, so time for a hardware hack! Let’s re-map the volume buttons of your phone into generic GPIO ports.

Continue reading »