OSCON 2013 – Go Talks

Twelve Go Best Practices

0xa things I love about Go

dl.google.com: Powered by Go


Introducing the Go Race Detector

“Race conditions are among the most insidious and elusive programming errors. They typically cause erratic and mysterious failures, often long after the code has been deployed to production. While Go’s concurrency mechanisms make it easy to write clean concurrent code, they don’t prevent race conditions. Care, diligence, and testing are required. And tools can help.

We’re happy to announce that Go 1.1 includes a race detector, a new tool for finding race conditions in Go code. It is currently available for Linux, OS X, and Windows systems with 64-bit x86 processors.

The race detector is based on the C/C++ ThreadSanitizer runtime library, which has been used to detect many errors in Google’s internal code base and in Chromium. The technology was integrated with Go in September 2012; since then it has detected 42 races in the standard library. It is now part of our continuous build process, where it continues to catch race conditions as they arise…”


The Lisp Bookshelf

“So I’ve obviously been paying a lot of attention to this site lately… so much so that I’m thinking of some sort of excuse for explaining the absence of decent reading material.

Jokes aside, I’ve recently gone through spells of intense study and absolute laziness. However, I have come across a gem of a website that has inspired this post, Programming-Musings by Jose Antonio Ortega Ruiz (Jao).

Jao is mainly a Scheme hacker and is the author of the well-known Geiser project, an interactive environment for Scheme in Emacs. I found his website by accident through a post in Hacker News, and read his post A Scheme Bookshelf which detailed his road to Scheme mastery.

I’ve been thinking of writing a similar post on my own study path of Common Lisp and reading his account finally made me decide to get on with it…”


Lifetimes of cryptographic hash functions

“Quick summary of my recommendations on compare-by-hash: If you are using compare-by-hash to generate addresses for data that can be supplied by malicious users, you should have a plan to migrate to a new hash every few years. For example, BitTorrent falls into this category, but rsync doesn’t. Keep in mind that new, more secure hashes are likely to have larger outputs (e.g., 256 bits for SHA-2 vs. 160 bits for SHA-1) and be more computationally expensive…”