Futures Is Stable on Rust 1.36(github.com) |
Futures Is Stable on Rust 1.36(github.com) |
[dependencies]
futures-preview = { version = "0.3.0-alpha.14", features = ["io-compat"] }
futures-util-preview = "0.3.0-alpha.14"
byteorder = "1.2.7"
clap = "2.32.0"
log = "0.4.3"
simple_logger = "0.5.0"
lazy_static = "1.2.0"
num-traits = "0.2"
num-derive = "0.2"
bytes = "0.4.12"
My source is on the order of ~1000 lines of (non-trivial) code and has 17 instances of 'async fn' and 23 instances of 'await!(...)'.Nightly 2018, --release, the resulting .exe is 990 KiB.
Futures themselves are very lightweight.
In general, Rust's big binaries are one of the things that puts me off the most. Even dynamic linking often doesn't help much. Then again, if a few MB, which is a rounding error nowadays, is among the worst I can think of, that's actually pretty amazing ;).
Rust's Futures allow for easy chaining, whereas I only implemented a simple callback that runs on completion, but it doesn't allow one to get at the computed value directly. I simply send a "check for updates" event there. Instead the value gets stored in a Mutex and has to be pulled out of that explicitly, although it can stay in the "Async" type, just that it gets stored directly in the struct after it's pulled out of the Mutex. The advantage is you don't have to pay for the locking all the time and the value can stay where it is, so you don't need to juggle it around. You can see it here: https://github.com/rabite0/hunter/blob/master/src/preview.rs...
I started working on an improved version that actually allows for a callback with a reference to the value upon completion and also a callback that moves the value out, but I haven't finished that yet and after seeing this I might not ever, but I probably will, since it's definitely educative.
Not asking for this to happen, I am just curious about the stabilization/release process.
0.1 was not, there's a lot of good and reliable software that's been built on 0.1, and there are some backward compatible shims for std::future to futures 0.1.
I really care about binary size, since for short running programs, or when startup latency is important it can actually be much faster in real time to have less, but slower code. Especially so on a slow HDD like in my laptop. Loading a few MB when it's under heavy load can take a few seconds.
Edit: Wow, LTO makes a huge difference. Almost a 40% smaller in my case AND it's faster. Really excited to try xargo now.