Comment by adastra22

Comment by adastra22 2 days ago

Even on Linux, you can't have '/' in a filename, or ':' on macOS. And this is without getting into issues related to the null byte in strings. Having a separate Path object that represents a filename or path + filename makes sense, because on every platform there are idiosyncratic requirements surrounding paths.

It maybe legacy cruft downstream of poorly thought out design decisions at the system/OS level, but we're stuck with it. And a language that doesn't provide the tooling necessary to muddle through this mess safely isn't a serious platform to build on, IMHO.

There is room for languages that explicitly make the tradeoff of being easy to use (e.g. a unified string type) at the cost of not handling many real world edge cases correctly. But these should not be used for serious things like backup systems where edge cases result in lost data. Go is making the tradeoff for language simplicity, while being marketed and positioned as a serious language for writing serious programs, which it is not.

const_cast 2 days ago

> Even on Linux, you can't have '/' in a filename, or ':' on macOS

Yes this is why all competent libraries don't actually use string for path. They have their own path data type because it's actually a different data type.

Again, you can do the Go thing and just use the broken string, but that's dumb and you shouldn't. They should look at C++ std::filesystem, it's actually quite good in this regard.

> And a language that doesn't provide the tooling necessary to muddle through this mess safely isn't a serious platform to build on, IMHO.

I agree, even PHP does a better job at this than Go, which is really saying something.

> Go is making the tradeoff for language simplicity, while being marketed and positioned as a serious language for writing serious programs, which it is not.

I would agree.

Reply View 4 replies

astrange 2 days ago

> Yes this is why all competent libraries don't actually use string for path. They have their own path data type because it's actually a different data type.
What is different about it? I don't see any constraints here relevant to having a different type. Note that this thread has already confused the issue, because they said filename and you said path. A path can contain /, it just happens to mean something.
If you want a better abstraction to locations of files on disk, then you shouldn't use paths at all, since they break if the file gets moved.

Reply View | 3 replies
- const_cast 2 days ago
  
  A string can contain characters a path cannot, depending on the operating system. So only some strings are valid paths.
  Typically the way you do this is you have the constructor for path do the validation or you use a static path::fromString() function.
  Also paths breaking when a file is moved is correct behavior sometimes. For example something like openFile() or moveFile() requires paths. Also path can be relative location.
  
  Reply View | 2 replies
  
  astrange a day ago
  
  > A string can contain characters a path cannot, depending on the operating system. So only some strings are valid paths.
  Can it? If you want to open a file with invalid UTF8 in the name, then the path has to contain that.
  And a path can contain the path separator - it's the filename that can't contain it.
  > For example something like openFile() or moveFile() requires paths.
  macOS has something called bookmark URLs that can contain things like inode numbers or addresses of network mounts. Apps use it to remember how to find recently opened files even if you've reorganized your disk or the mount has dropped off.
  IIRC it does resolve to a path so it can use open() eventually, but you could imagine an alternative. Well, security issues aside.
  
  Reply View | 1 reply
  
  adastra22 a day ago
  
  Rust allows null bytes in str. Most (all?) OS don't allow null bytes in filenames.
  
  Reply View | 0 replies