My immediate comments on the general proposal (a better IO library) and also this specific proposal (better-files).
Scala does obviously need a better situation for IO, deferring to Java IO is less than ideal for many reasons
- The API is overly verbose
- It probably reflects the JVM platform to closely (matters for stuff like Scala.js and possibly scala-native).
The issue is that doing an IO library is not a trivial task, there are a lot of things to take into consideration especially how large your scope is, i.e. should we only be handling basic stuff that you would see in something like Python (aka reading items in one line) or should we also handle more complex stuff like streaming and async (i.e. providing an async implementation that returns
Regarding this specific proposal, I have the following remarks
- Will the library possibly be renamed? If we are doing a IO library, something that is very central to languages in general, it should probably be called scala.io and be in a
scala.iopackage or something along those lines
- Re-iterating @jvican point, the interface should not expose any Java like stuff and it should be idiomatically Scala.
- 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 (so this library wouldn’t be a nice design for a platform agnostic IO)
In conclusion, if we are going to do the hard task of providing a Scala IO library, its something that should be done correctly and with some future proofing in mind, and I don’t think that a light wrapper over Java’s NIO fullfills this task. The Scala.io proposal should be very idiomatically Scala, and shouldn’t (for default usage) expose Java NIO details (obviously we can bring in this functionality similarly to how java converters work for collections)
From a design perspective I like that the API is simple, I just think that it should abstract over more of the JVM specific details