3 ms·
> I can't remember the last time I came across a modern language where the "easy default" is unbuffered I/O. Java. There In that regard it got turned weirded
by xxs 5y ago
> I can't remember the last time I came across a modern language where the "easy default" is unbuffered I/O.
Java. There
In that regard it got turned weirded with multiple buffers which slows down as well, just on as much as totally unbuffered. Java 1.4 added nio where the buffers were part of the framework.
- BoorishBears 5y agoI mentioned Java didn't I? Even in the pre-NIO APIs: If you try to write a string to a FileOutputStream the way that Rust code did this is what it looks like: byte[] byteString = "Hello World".getBytes(StandardCharsets.US_ASCII); myStream.write(byteString, 0, byteString.length); But if you use a FileWriter, which has a built-in buffer and wraps the OutputStream: myWriter.write("Hello World"); For me, if the Rust example had required a length and offset, I'd immediately assume it was unbuffered. I keep clarifying: I realize it's not a rule, but I guess that's just a pattern I've seen across a lot of languages. Maybe because it somewhat matches write(2)?
- xxs 5y agoIndeed, Reader/Writer framerwork provides buffering (esp. now). However, in my experience the writers are not very commonly used which is a stark contrast to BufferedReader that's everywhere (it comes with readLine()). Instead, writing is commonly implemented via encoding/conversion/etc. to a byte[] and then written directly to the output stream.