PSA: continuing discussion for IO/OS reform

[aturon]

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:

RFC: io and os reform: initial skeleton

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!

[aturon]

New PRs open for discussion (more to come soon):

• Reader/writer and core::io
• String handling
• Deadlines
• std::env
• std::process

[bluss]

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.

[jminer]

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.

[mrec]

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?

[d3zd3z]

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.

[mrec]

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.

[alexcrichton]

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”

[aturon]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.