cc @mikioh

You need to deal with the number of bytes received appropriately like the following:

b := make([]byte, 2048)
for {
	n, err := c.Read(b)
	if err != nil {
		fmt.Println(err)
		return
	}
	fmt.Printf("%s", b[:n])

For more questions, please take a look at https://github.com/golang/go/wiki/Questions.

@mikioh example clarification: Shouldn't that print come before the error check?

b := make([]byte, 2048)
for {
	n, err := c.Read(b)
	fmt.Printf("%s", b[:n])
	if err != nil {
		fmt.Println(err)
		return
	}

go doc io.Reader

Callers should always process the n > 0 bytes returned before considering
the error err. Doing so correctly handles I/O errors that happen after
reading some bytes and also both of the allowed EOF behaviors.

Shouldn't that print come before the error check?

The net.UDPConn conforms to not only io.Reader interface but net.Conn and net.PacketConn interfaces. In addition, the net.UDPConn doesn't implement a few features that satisfy io.Reader interface such as returning io.EOF at the message, I mean, a unit of data exchange, boundary.

Can we rely on io.Reader interface over net.UDPConn? That's a good question, though, I still have no concrete answer. It's probably okay w/ a few limitations such as io.EOF on almost all the existing implementations, but there will probably be exceptions, for example, on platforms enabling fancy LRO (large-receive-optimization) under heavy load, a microcode in some networking peripheral may advise that it perhaps returns an error with a corrupted number of bytes transferred because of the lack of spare logic-gates or machine cycles.