How is the cost in terms of binary size nowadays? Last time I checked using Futures meant adding roughly 5MB to the binary. To me at least that is unacceptable, so I just rolled my own stuff on top of rayon's thread pools.
Ah, yes, that was probably it. I stopped looking into Rust's Futures pretty much as soon as I noticed how heavyweight the required runtime is, which seemed ridiculous to me, since Futures are so simple conceptually. I have to look into this again.
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 ;).
When Rust switched to the system allocator by default, that slimmed down the minimum size quite a bit. In addition to that, where size matters, there are some articles about how to slim it down even more, here's an example: https://github.com/johnthagen/min-sized-rust
Thanks for the link! I knew about strip, which helps a lot, but the other options look promising as well.
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.
It was the runtime required to actually run the Futures.
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.
Sorry if that wasn't clear, it's been a rather long time since I checked on the Future story. There seem to be more options now than when I looked into it. When I did my research over half a year ago tokio seemed to be the only option. Glad to see that's not the case any more.
It’s all good! To elaborate a bit, there’s a trait, Executor, that people can implement to build these kinds of things. This stuff, along with the final version of Futures, stabilized a few days ago. But it’s been baking a while.
Nightly 2018, --release, the resulting .exe is 990 KiB.