> But then you would have to wrap one-liners more often.

Would you really? Most of the examples I see over and over take no argument, the common case most definitely seem to be that. Not to mention it is not hard to design a HoF wrapping a callable and arguments, and deferring the application of one to the others.

> The syntax of the 'defer' keyword is obviously designed to match the syntax of the 'go' keyword for launching Goroutines

Which I consider problematic for the same issue.

> it would be annoying to wrap every 'go' call with arguments in an anonymous function without arguments.

No more annoying that calling functions being deferred, or coping with the weird irregularity of evaluating all sub-expressions but not the top-level one.

Which is why "defer" and the "go" should operate on blocks or statements, not expressions. For instance:

    defer { result++; }

Instead of:

    defer func() {
        result++;
    }();

Also that you need such an ugly syntax just to not silently ignore return values from "defer" and "go" speaks volumes. For instance the "defer f.Close()" in the original post ignores errors from close, and with no exceptions these are just lost. It should be something more like:

    defer func() {
        err := f.Close();
        // handle error
    }();

You are basically always going to use this form anyway if you care about error handling. But lack of error handling in Google Go is another issue entirely.