Hacker News Reader

Comment by jeffbee | Hacker News Reader

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.

View on HN

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...

> And further, Cloud file systems do have mode, and directory...

The most popular cloud file system, S3, doesn't have folders. It has prefixes, but if you treat them like folders, you're in for a lot of pain.

Colossus doesn't have directories either.

http://www.pdsw.org/pdsw-discs17/slides/PDSW-DISCS-Google-Ke...

Page 9

What are the pains when treating prefix as directories?

I am not familiar with S3.

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.

Reply on news.ycombinator.com