Please update futures-rs to 0.3.1

[Silentdoer]

Hi, please update futures to 0.3.1

[Luminoth]

It would be great if an update to tokio 0.2 could come along with this

[fafhrd91]

tokio team did nice thing, actix now is not compatible with tokio anymore

[cdbattags]

@fafhrd91 what?! How so?!

[cdbattags]

This framework is one of the biggest built on top of tokio so I think we'd have some weight for asking for backwards compatibility of a certain form.

What changed in last few days?

[fafhrd91]

You can not spawn !Send futures anymore. I am planing to add custom runtime and drop tokio dependency

[cdbattags]

So something specific in the executor? Any idea why this new design decision?

Wouldn't building a runtime for actix be quite a huge feat? Why not just fork and add feature to tokio worst case?

[fafhrd91]

Actix is single threaded, tokio mostly multithreaded. Actix does not need any complexity

[asonix]

There exists work to provide support for !Send futures in tokio: tokio-rs/tokio#1733

Rather than introduce an additional asynchronous runtime (we already have tokio and async-std) it might be worth waiting for tokio to again support !Send

[fafhrd91]

actix uses maybe 10-15% of tokio, I am not sure why I need other 85% all the time.

[fafhrd91]

But obviously, modularity is not a concern anymore.

[cdbattags]

Async-std works currently? That's news to me. Where can I find the different runtime "modules" source code? And any instructions for implementing a new one?

Which actix repos/folders to dig into?

[asonix]

@cdbattags I wasn't trying to imply that actix works on top of async-std or tokio 0.2, I was just stating that these options exist as asynchronous runtimes, and I didn't think introducing a third asynchronous runtime was a good idea.

[cdbattags]

Ahhh @asonix you were just referring to there existing multiple runtimes for futures in the Rust eco right now?

@fafhrd91 the way I look at it is that the 85% we don't use slows crate/package download time and compile time but that's about it, no?

If we need to reduce binary size later we can approach a new runtime then, no?

And why is modularity "not a concern anymore"?

[hawkw]

FWIW, in the new tokio 0.2 release, it should be much easier for crates like Actix to opt in only to the features they use, via feature flags: tokio-rs/tokio#1811

This was intended primarily for libraries which need only some features from tokio but don't want to burden their users with longer compile times. :)

And, spawning !Send futures will probably have made it back in by tokio 0.2.1 — we know that's currently a blocker for some use cases!

[fafhrd91]

At the moment we are evaluating option to drop tokio completely

[krircc]

@cdbattags Current async-std also can not spawn !Send futures

[hawkw]

The current master version of tokio now has an API for spawning !Send futures, and it should be released in the near future. Hopefully this helps!

[extrawurst]

and its released: https://github.com/tokio-rs/tokio/releases/tag/tokio-0.2.1

[cdbattags]

and its released: https://github.com/tokio-rs/tokio/releases/tag/tokio-0.2.1

Thoughts, @fafhrd91?

[kanekv]

Btw, if actix moves away from tokio it will be painful to use other crates that require tokio runtime (tonic, hyper, etc)?

[carllerche]

@fafhrd91 It's unfortunate to hear, I would be eager to talk out the points in 0.2 that don't work for you. I had reached out to you in the past to ask for early feedback to make sure the changes worked for Actix, but unfortunately you did not have any availability. We did our best to ensure that the Actix case was covered.

But obviously, modularity is not a concern anymore.

Modularity is a big concern. Using feature flags, we can reduce the total amount of code while providing greater flexibility (mixing feature flags cross crates did not work very well). You can still only enable the components that you need. If there is something more specific, I would love to hear it.

You can not spawn !Send futures anymore.

As mentioned by others, this is now supported. The very initial release of 0.2 shipped without task::LocalSet, but mostly to get something out the door as task::LocalSet is forwards compatible. I would say that being able to fully decouple the concern of scheduling !Send tasks from the concern of I/O shows greater modularity?

Anyway, if you have specific issues you wish to discuss, please ping me or open an issue on the Tokio repo and I would be happy to work through them.

[fafhrd91]

My initial thoughts was related to 0.2.0 release. I think LocalSet should work.

Closing ticket as path for actix actors to async/await is not clear yet

[gzp79]

And what about projects those are targeting actix-web 2.0 and require the Actor model ? Is there another tracking issue for this? For now the actix-web 2.0 without actor model is a huge braking change that'll hurt many projects.
If there is an alternative solution than please provide a migration guide.

[glademiller]

Just to add my two cents for my use case I'm actually working on alternative implementations to the few actors I am using in my projects since most of them don't strictly require an actor model but I totally agree at least in the near term this is driving my projects to leave actix behind.

…

On Wed, Dec 4, 2019, 09:08 gzp-crey ***@***.***> wrote: And what about projects those are targeting actix-web 2.0 and require the Actor model ? Is there another tracking issue for this? For now the actix-web 2.0 without actor model is a huge braking change that'll hurt many projects. If there is an alternative solution than please provide a migration guide. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#298?email_source=notifications&email_token=AAPJZBE3RQH7B6F4YKUU373QW7PYLA5CNFSM4JRF4ZW2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEF5XSSY#issuecomment-561740107>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAPJZBCAQUFS3QV4UKZV5M3QW7PYLANCNFSM4JRF4ZWQ> .

[HugoKempfer]

Did #300 solves the issue?

[Luminoth]

Seems like it should have. I'm wondering if that also means we can use async / await with actix now.