Futures Is Stable on Rust 1.36 | Hacker News Reader

Futures Is Stable on Rust 1.36

github.com

63 pointsr0xsh19 comments

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.

I just made a socket server for a small protocol, no (explicit) Tokio.

  [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.

And that is without stripping

You're probably thinking of the Tokio library in regards to the size, though I can't right now validate the size.

Futures themselves are very lightweight.

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.

Where does the bloat come from? Which features are offered by the standard futures that you left out in your implementation?

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.

To be clear, it's "a" runtime, not the runtime. It's the most popular one, but there's others as well, and some focus on embedded and binary size.

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.

If the current version of rust is 1.34.1, and futures is stabilized, why not 1.35?

Not asking for this to happen, I am just curious about the stabilization/release process.

If the current stable version of Rust is 1.34, the current beta version of Rust is 1.35, and the currently nightly version of Rust (which is where major changes, including stabilization of features, are made) is 1.36.

This should solve a major bottleneck for anyone doing network related applications. For now, you have to use an unstable API or a one that is deprecated.

0.2 was deprecated.

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.

July 4th

1.36 is due by June 4th.

ah, right. thanks for your correction

Reply on news.ycombinator.com