4 ms·

I kind of understand why Rust made buffered IO explicit and on-demand instead of going down the C route and making it the default, but still I think there's a s

I kind of understand why Rust made buffered IO explicit and on-demand instead of going down the C route and making it the default, but still I think there's a significant risk lots of programs are going to be suboptimal due to developer ignorance or the expectation of having buffered IO by default like with stdio and iostreams. It would have been IMHO probably less clean but safer to make the standard IO constructs like File buffered by default (which is what users expect in the vast majority of cases) and provide on the side unbuffered variants. Thankfully modern OSes with caches and stuff somewhat mitigate this thing, but it can make IO on less advanced systems way more problematic than it should be.

brundolf 5y ago
I think it would go against Rust's philosophy to have hidden (and inconsistent) behavior, like automatically buffering some things but not others. Generally Rust tries to give users explicit and ergonomic control over those sorts of details.
- lumost 5y ago
  When developing large scale applications ( e.g. any app that needs third-party libraries ). You are going to have to deal with developers who either 1. Didn't know about a nuance. 2. Didn't care about said nuance. Creating magic incantations to achieve typical expected behavior will result in many libraries doing the unexpected behavior. Which means that the typical code that any end user works with will probably do the unexpected thing.
  - brundolf 5y ago
    It's all relative. I'm very glad that JavaScript doesn't try to make you deal with output buffers, but Rust's goals as a language are different.
    - qalmakka 5y ago
      The problem here is that the uncontested ruler of said system languages, C, has a completely opposite behaviour by default. The C standard clearly states that "When opened, a stream is fully buffered if and only if it can be determined not to refer to an interactive device" (§7.21.5.3.8), which means that generations of developers have learned to always expect buffering when opening files `fopen`. Most higher level languages follow the C library when setting their I/O convention, and this has been the trend for most of the last 40 years. The fact that Rust goes in the opposite direction makes sense from a logical standpoint, but as the article itself shows will almost certainly end up causing performance issues. You can rest assured that people *will* forget to buffer their files because it is something they almost never had to care about in the past.
  - spoiler 5y ago
    It's clearly documented in multiple places that it's unbuffered (fs docs, io docs) What's magical here? Rust makes it there's no need for magic. Most things like these are designed to compose. Here it's no different, and certainly not any more magical.

brundolf 5y ago

I think it would go against Rust's philosophy to have hidden (and inconsistent) behavior, like automatically buffering some things but not others. Generally Rust tries to give users explicit and ergonomic control over those sorts of details.

lumost 5y ago
When developing large scale applications ( e.g. any app that needs third-party libraries ). You are going to have to deal with developers who either 1. Didn't know about a nuance. 2. Didn't care about said nuance. Creating magic incantations to achieve typical expected behavior will result in many libraries doing the unexpected behavior. Which means that the typical code that any end user works with will probably do the unexpected thing.
- brundolf 5y ago
  It's all relative. I'm very glad that JavaScript doesn't try to make you deal with output buffers, but Rust's goals as a language are different.
  - qalmakka 5y ago
    The problem here is that the uncontested ruler of said system languages, C, has a completely opposite behaviour by default. The C standard clearly states that "When opened, a stream is fully buffered if and only if it can be determined not to refer to an interactive device" (§7.21.5.3.8), which means that generations of developers have learned to always expect buffering when opening files `fopen`. Most higher level languages follow the C library when setting their I/O convention, and this has been the trend for most of the last 40 years. The fact that Rust goes in the opposite direction makes sense from a logical standpoint, but as the article itself shows will almost certainly end up causing performance issues. You can rest assured that people *will* forget to buffer their files because it is something they almost never had to care about in the past.
- spoiler 5y ago
  It's clearly documented in multiple places that it's unbuffered (fs docs, io docs) What's magical here? Rust makes it there's no need for magic. Most things like these are designed to compose. Here it's no different, and certainly not any more magical.