I think the tokio/async ecosystem just isn't ready for prime time. Hopefully this (and compile times!) get much better.

The issue isn't exactly that it's not ready for prime time, but that it's not ergonomic at the moment. The biggest issue that you have to get used to is that pretty much everything has to be owned data, and no references passed around when constructing Future types. This can feel like it comes into conflict with the poll(&mut self) interface (in 0.1).

Also, I found truly understanding the fact that returning data from functions either must be sized or boxed, no references. Again, the &mut self can come into conflict here. But there are simple tricks for dealing with it, like using inner enums for iterating through a state machine of the future, and using Option where you can take() the value when ready.

You'll see these patterns if you look at the Future library and Tokio impls of many of the core types. So I encourage you to generate docs with `cargo doc` and then click the `src` link on any types you want to understand better. The thing I wish I had internalized more earlier (and have been cleaning up a lot lately), is that "Futures should do no work unless polled". This is easy to mess up and regret later as you might accidentally start a Timer or initiate a connection before polling the Future.

Anyway, hopefully people help out when you ask, though everyone's often busy :)

One of the challenges I'm having now is with some library that connects to a steaming pubsub server. I found a problem with the library, my use-case differs from what's being tested, and because I'm struggling to use the library the way the author suggests; I'm unable to convince them that being unable to Clone their data structure is causing a problem.

I unfortunately am not at the point of "X didn't work, so I wrote Y" as that's how we end up with competing libraries.

Sometimes there are good reasons for not cloning, such as underlying resources that can’t be cloned. But I agreed it can be ergonomically easier in many cases. If they truly don’t want it, and you really don’t want to fork, can rewrapping it in an Arc<T> or Arc<Mutex<T>> get you around the problem?

Wait, if I do (in any language)

  foo = createFuture(1)
  bar = createFuture(2)
  foo.poll()
  bar.poll()

I would expect them to start doing work before polled, otherwise there'd be no concurrency. Do I undsrstand you correctly about polling?

You didn’t say what you understood, but nothing would happen until poll is called in Rust. And calling poll would only result in one churn of the event loop. You don’t call poll yourself, you put the future onto an event loop and it calls poll for you.

While compile times can be slow, the rust system is checking so much for you, so that you can have a predictable @scale runtime. What was the issue with tokio? Plus, with async/await Futures coming in soon, already on nightly right, this should become good if not already? Rust went down the Kotlin route of not including coroutines/async/await initially and allowed Lib devs to build, but now have included as we all know. But anyways, keep at it, I have found Rust to be very helpful, using it at the startup I am at, and will keep using it deeper and in more complex scenarios.

Rust is checking a lot, but type checking is not the slow part! (I can usually run cargo check within a couple of seconds max). Rusts LLVM IR output, LLVM, and linking seem to be the main culprits. And I'm hopeful that these can be greatly improved :)

Oof, I got burned by the tokio/futures ecosystem too. It's definitely a frustrating experience. Thank god it was only a pet project with no deadline pressure, cause it's been 6months now and I'm still waiting for stabilization.

I spent two years of my professional career with Rust doing async web services and most of it with tokio/futurrs. First you finally get comfortable with Rust and then you do the learning again with futures... I did it. It paid off. Wrote some fast and stable services with it and it is not that hard when you get to the other side.

But for newcomers, be careful with references when using futures and be smart how you use the combinators. The errors can be tough and this is the only place in Rust ecosystem where they don't really help at all sometimes.

I eventually got something working, and it was stupid stupid fast, but it definitely took a lot longer to write than I would've liked.

Just waiting for the features and APIs to finalize and async/await for the ergonomics improvements. I believe in it's potential, but I'm in no hurry to use it again in it's current state.

Didn't mean though I think the current situation is that bad. What you get already is a type safe way to build async programs where the runtime is separated from the logic. I remember switching from a single threaded event loop into a work-stealing threadpool by just changing one line of code. It's very explicit and nice.

Which stabilization?

async/await is the big one :)

I guessed, it’s huge for sure :) since everything does work on stable, I wasn’t sure if there was something else I was missing, or if you meant the libraries, which still have some churn to go.

I can’t wait myself.