I am not a fan of just being a very light wrapper around Java NIO, mainly because I think we should be caring for multiple platforms and hence stuff like scala-native shouldn’t have any concepts of java-nio
There is no reason we can’t implement a facade for java.nio in scala-native, or for that matter in Scala.js for all the synchronous APIs that exist (in-memory FS, node’s sync FS, …). That’s what we’ve done with Java collections, for example, and the effort required is relatively trivial compared to designing a whole new IO library from scratch.
There are plenty of reasons to want something better than better files (betterer files?) but scala-native/scala-js compatibility is not one of them. I’ve reimplemented a large chunk of java.io.File in Scala.js in-memory to port some Scala-JVM code; took less than an hour to get quite good coverage, and I see no reason that java.nio would be different.
IMO this is a showstopper for the idea of writing a new IO library satisfying whatever monadic/async/portable/etc. criterion and putting it in the platform. The platform should be about stability and consensus, not experimentation and research. But I’m of the opinion that any candidate library should already exist and have a reasonably large following before being considered for inclusion in the “scala platform”, whichever interpretation of that term you want to take.
That’s not to say we can’t go and write a whole new Scala IO library and explore; it’s just that an add-to-platform-proposal is not the place to brainstorm ideas for that. “no library is satisfactory, including this one, is satisfactory to include in the platform” would also be a fine answer here, but let’s not kid ourselves that there’s a whole new idiomatic, good, safe, monadic, async, cross-platform IO library just around the corner…