Riemann metrics demo

main.go

package main

import (
	"github.com/pingles/go-metrics"
	"github.com/pingles/go-metrics/riemann"
	"log"
	"net"
	"time"
)

var (
	connCounter = metrics.NewCounter()
)

func handleConnection(conn net.Conn) {
	connCounter.Inc(1)

	defer conn.Close()
	defer func() { connCounter.Dec(1) }()

	conn.Write([]byte("Hello, world..."))
	time.Sleep(time.Second * 5)
	conn.Write([]byte("goodbye!\n"))
}

func main() {
	metrics.Register("open-connections", connCounter)

	// starts a reporter pushing metrics to Riemann
	// every second
	go riemann.Riemann(metrics.DefaultRegistry, time.Second, "localhost:5555")

	addr, err := net.ResolveTCPAddr("tcp4", "127.0.0.1:9100")
	if err != nil {
		panic(err)
	}

	listen, err := net.ListenTCP("tcp", addr)
	if err != nil {
		panic(err)
	}

	log.Println("listening on", addr)

	for {
		conn, err := listen.Accept()
		if err != nil {
			log.Println(err)
			continue
		}
		go handleConnection(conn)
	}
}

Go seems to syntactically enforce some maintainability anti-patterns. I'd like to understand from an advocate whether these trade-offs are worth it.
For example, I'm not a big fan of multiple return values or enforced multiline ifs (especially for guard clauses). These occur at lines 33-36, 38-41 and 46-50
I think a better pattern where the second return value is an error code would be to pass in an error function:

addr := net.ResolveTCPAddr("tcp4", "127.0.0.1:9100", panicOnError)
listen := net.ListenTCP("tcp", addr, panicOnError)
conn := listen.Accept(logAndContinueOnError)

What are your thoughts?