Yes, you can do that, but I don't think it would be a very honest implementation. You're not reading something in a particular way; you're writing it in one. If the code could use two different data sources, overriding the reader to deal with protocol differences would make sense. (I actually did the first implementation using the `ReaderFrom` interface, but decided against because it didn't feel right.)

The intent is not to eliminate duplication (if anything, it's [SOLID](https://en.wikipedia.org/wiki/Solid_(object-oriented_design))), but to write composable, maintainable and testable code. I don't agree the readability suffers: It's easy to understand the tail command; it scans lines and writes them. It's easy to understand the line writer; it takes a string and formats it as a line. It's easy to understand the colorizer; it applies colors based on a defined format.

That said, I'd love to get rid of the adapter. It's just boilerplate to satisfy the compiler, but unfortunately it's required. I thought about moving it to a separate file as there's really no need to deal with it when parsing the command, but I don't know a thing about organizing Go code.