I think this is an excellent summary and I agree with all of it. > Go has chosen a dualistic perspective, like with the particle/wave dualism in physics. This

I think this is an excellent summary and I agree with all of it. > Go has chosen a dualistic perspective, like with the particle/wave dualism in physics. This summarizes my complaint. It's not consistent. It forces me to switch between perspectives and keep two contradictory models in my head. As I said, it's not the worst thing -- I can deal with it. But I consider it a kind of conceptual wart in the design, or at least of the naming conventions and idioms. A final pedantic point. I find your interpretation of "ebook reader" interesting, and grant that it is a valid one, and fits with the Go "thing as tool" perspective. However, I don't believe it is the perspective most people use in everyday life, and I think the dictionary definition makes this clear: e-reader (noun) -- a portable electronic device used for reading books and other text materials that are in digital form. That is, and e-reader is the thing, the object, the book-substitute that you read. From: https://www.dictionary.com/browse/ebook%20reader https://www.dictionary.com/browse/ebook%20reader EDIT: on 2nd thought, maybe that definition does back up your interpretation. "device used for reading books..." I still feel like in practice it is modeled in people's minds just like a "different kind of book" but maybe that is just me, or just some people.... EDIT 2: > In other experiments, it is an object which can read data from the OS and return it to you (e.g. file.Read()...) My other objection here (as I pointed out elsewhere) is that if I am supposed to take the "interface as tool" perspective when interpreting the "Reader.Read()" method, then the variable "file" is misnamed. I read a file, I don't use a file as a reader to read a file. Since I can only name a variable according to one perspective, the name will always feel wrong when I switch to the other.