It would not be safe to attempt to provide a Go io.Writer that backs to some file descriptor and backs to writev. The text of the io.Writer interface forbids the io.Writer from modifying the passed-in []byte, which implies strongly that the caller is still considered to own it. Also, the fact that I said &quot;implied&quot; is awfully scary too. You can&#x27;t buffer things easily because you can&#x27;t reliably know when the last .Write is called, and all the solutions I can come up with will annihilate any conceivable performance advantage (i.e., if you&#x27;re communicating across to some other goroutine, you just lost the performance). Especially since if you don&#x27;t write it right away, you almost certainly must take a copy to be safe, and, oops, there went all the performance advantage again. The need to take a copy also prevents you from just declaring it has to be flushable; it&#x27;s legal for something using a Writer to mutate a buffer and pass chunks of it in multiple times, and I&#x27;m pretty sure I&#x27;ve already got code that does that. No point in buffering up several slices if the caller is going to mutate it between invoking .Write calls.<p>What you could do is create an object that implements, say, interface{ Multiwrite([][]byte) (int, error) }, that also implements io.Writer as a fallback in terms of the Multiwrite so this object is generally useful, but that still gets you no performance win for text&#x2F;template unless it is modified to incorporate this new interface.<p>However, that does seem like it&#x27;s at least a possibility; there are, for instance, already optimizations in net&#x2F;http for serving up files via the Linux sendfile kernel call, and this would be pretty similar. Providing implementations of Multiwriter for a file and a socket might not be a tough sell; complexifying text&#x2F;template to actually use it in the core library might be, though. Depends on what kind of performance numbers you can show.