People still seem to complain about the compiler error: x declared but not used. The documentation in the faq claims that this may indicate a bug, but doesn't make much of an effort to convince you of this. The declared but not used compiler error actually catches a common class of bug related to Go's type inference declaration which could be very difficult to spot otherwise.

Lets look at this with an example I encountered while writing some real code. You start with a function:

func writeColumnSql(sql *bytes.Buffer, table *TableMap, col *ColMap) {
    sqltype := table.dbmap.Dialect.ToSqlType(col)
    ...
}

Now, you add a new feature, and want to make a new, different initialization case the default, and only override with the old method as a fallback:

func writeColumnSql(sql *bytes.Buffer, table *TableMap, col *ColMap) {
    sqltype := col.sqltype
    if len(sqltype) == 0 {
        sqltype := table.dbmap.Dialect.ToSqlType(col)
    }
    ...
}

The code now does not work as intended. Here in the context of explaining this class of error, it might seem obvious, but it is made absolutely clear by the compiler error. The second sqltype declaration does not affect the outer sqltype variable; it creates a new variable inside its own scope called sqltype which then goes unused and drops out of scope.

Unused variables provide no value to your program, consume memory you are not using, and can potentially be bugs. The pain of having the odd initial development phase compilation fail is heavily outweighed by the enforcement of this good habit and the ability to quickly detect these errors.

Jun 2 2013