Do people really sing the praises of File? Or, do they curse its many and dangerous rough edges?
Like you I read this proposal through that lens, but I actually don't see a line from Google's File abstraction to this. Is this Go abstraction really forward-compatible with cloud-native filesystems? And when I say forward compatible I mean would it work with Google's decade-old Colossus? I think it isn't because it puts Stat in the required interface and Stat returns FileInfo, many of the fields of which might be meaningless in a cloud filesystem (like mode, which is a unixism, and IsDir, which doesn't make sense for non-hierarchical filesystems).
If you can't tell I'm not much of a fan of trying to abstract over filesystems. Mostly they don't resemble each other at all, except in some extremely high level concepts.
So first, what exactly I was meant to say, is that:
Go design resembles closest to Google's internal C++ APIs.
Then, when I saw people praises Go APIs, I feel that some people worked on C++ APIs at Google, were missing some credits. That's a derived feeling from the above.
That is not to say that this File design was already being praised (not to say that it does not deserve praise); or that it should be criticized (not to say that it does not have problems).
As for your example to contradict my claim: "Stat returns FileInfo, many of the fields of which might be meaningless in a cloud filesystem":
1. This has to be there because a File API has to be compatible with OS files (Unixy). And Google's API also does the same thing.
2. Incompatibility derives from enforcing information that not present in another scenario. Clearly, the presence of such attributes does not prevent them to be applied on cloud files systems.
And further, Cloud file systems do have mode, and directory...
IsDir can return false for filesystems that don't have that concept, which would of course be the correct value in that case. Mode and ModTime are more concerning, but practically, FileMode(0) and time.Time{} can be used respectively in implementations that have no use for them.
In terms of the ideal of preferring types as a means to constrain functionality, I think FileInfo fields should have been expressed as granularly as possible using extension interfaces in this case, but practically I'd prefer putting some placeholder values in FileInfo for missing functionality over the clunky way these extensions have to be implemented in in Go.
Maybe Ken Thompson and Rob Pike worked on those C++ APIs, too. They certainly don't like C++, but also had to used it, and created Go out of frustration.
There is no exception for this API either.
I kind of feel weird when there has been loud praise on Go team, while in general it was no mention of the decade of hard work of evolving C++ APIs...