Closed yorickpeterse closed 1 week ago
To add another reason for not buffering STDOUT: for certain scenarios you might want to automatically disable buffering, such as when running the program in a pipeline. For this we'd need https://github.com/inko-lang/inko/issues/634, which in turn requires more work.
A brief overview of what some languages do:
Language | STDOUT |
---|---|
C# | buffered |
Crystal | buffered, though it has a helper method for automatically flushing |
D | buffered |
Go | unbuffered? |
Julia | line buffered? |
Node.js | unsure, seems to be synchornized? |
Python | buffered |
Rust | line buffered |
Swift | block buffered? |
To add to the above: while the language may do one thing, the underlying platform may do something else. For example, libc still buffers STDOUT by default unless you explicitly disable this using setvbuf()
.
Another note: if we want to ensure that STDOUT
and such always use the file descriptors 0, 1, and 2, we need to first take care of https://github.com/inko-lang/inko/issues/633, such that files in Inko are just wrappers around file descriptors instead of opaque Rust values.
Description
These types currently make use of the Rust runtime library, and wrap the Rust types. There's however no need for this:
/dev/stdout
/ etcprintln!()
macro). This isn't needed for Inko though since we require one to create an explicit instance, and there's no way to stick these types in a globalImplementation wise I'm leaning towards not buffering STDOUT by default. With 988b72191f4aa66a3ac4f95dcf07b88634bad7de it's possible to perform buffered writes, meaning you can opt-in to buffered writes if desired, while opting out would require a separate type (e.g.
STDOUT
andUnbufferedSTDOUT
/UnbufferedStdout
?).As part of this we should also rename these types as follows:
STDOUT -> Stdout
STDERR -> Stderr
STDIN -> Stdin
Blocked by
Related work