Now that alpha has been released, I'd like to turn some attention back to IO/OS reform.
The RFC and previous comment thread were both of record-breaking length, and discussion has stalled.
To help move things forward, the core team has decided to split the RFC up into pieces that all fit into a common skeleton. You can read more about the plan here:
I'll be filing follow-up PRs for the individual pieces shortly. Please take a look at these PRs and join in on the discussions to help iterate on the design!
I don’t know in which tread this fits best: Give attention to FileStat and the created field (issue link). It’s filled with ctime on all platforms, only representing the created date on some.
Reading the design principles, I’m really happy to see API naming be platform-neutral and follow Rust conventions. Too many languages (e.g. Ruby, Python, PHP, Node) use Unix function names like unlink or stat, so it is great to see Rust feel less out of place on Windows.
The I/O library design has been mentioned in the past as a major contributor to the unfortunate size of a statically-linked hello_world executable. Example 2014-01-02 comment from alexcrichton here; he says *“This is a consequence of our decision of the architecture of I/O and I don’t forsee it changing soon.”
It’s not clear whether the “it” he doesn’t forsee changing refers to the consequence or the architecture, but since the latter does now appear to be changing, is this considered in scope? Or is everybody now resigned to having multi-megabyte hello_worlds forever?
I’m not sure this is really as bad as people are making it out to be. The primary difference seems to be that libc is almost always linked dynamically, whereas rustc seems to be pulling in libstd (and friends) statically.
As a (not very meaningful) comparison, with x86_64, simple println!("Hello world"); and an equivalent in C with printf
$ rustc -O hello_rust.rs
$ size ./hello_rust
text data bss dec hex filename
374774 13768 4736 393278 6003e hello_rust
and
$ gcc -static -O -o hello_c hello.c
$ size ./hello_c
text data bss dec hex filename
741430 7852 9144 758426 b929a hello_c
This isn’t really a meaningful comparison, since the rust executable is still dynamically linking against libc. But, the only way C is getting a size of only a few thousand bytes is because most of the stuff is dynamically linked.
I wasn’t able to figure out how to get rustc to statically link against libc.
I think @alexcrichton’s “architecture” point there was about large vtables in io pulling in the implementations of all their methods whether the executable needs them or not, rather than static vs dynamic linking, but I don’t want to put words in his mouth and things may have moved on by now anyway.
The I/O library design has been mentioned in the past as a major contributor to the unfortunate size of a statically-linked hello_world executable
With the removal of the green/native runtime split, this issue has actually since been addressed. There is no longer any "forced bloat" for I/O that you don't use, the linker strips away all of it.
Turns I out I was wrong when I said "I don't forsee it changing soon"
