3 ms·

Congratulations to all involved. Huge milestone! That said, I’ve been using it seriously on nightly for a while already… and must say its ergonomics are off pu

by gdcbe 3y ago

Congratulations to all involved. Huge milestone! That said, I’ve been using it seriously on nightly for a while already… and must say its ergonomics are off putting. For example I maintain https://github.com/plabayo/tower-async https://github.com/plabayo/tower-async (a fork of tower), and on its own it looks to work (except for the boxing and dynamic dispatching others have already discussed). But once you throw it into the tokio ecosystem, building on top of something like hyper, and you suddenly are back into nightly territory due to having to specify trait bound for your async fn trait methods (eg: call(): Send). It works, and you can see in my early WIP proxy repo (https://github.com/plabayo/rama https://github.com/plabayo/rama). It’s not pretty but does work… that said it does put you in a nightly position once again due to having to specify Send/Sync trait bounds of trait async fn methods opaque futures… In contrast the RFC that would allow me to write ‘type Future = impl Future<…’ seems to fit a lot better in the existing tokio ecosystem. Just my 2 cents. Anyway, I get its hard work and WIP, so congratulations again and thx for all the work! (Edit: I do understand that the main source of my issues is due to the combination of writing very generic code and using multithreaded async (via tokio). Still, it’s not pretty. But perhaps it’s also because I still have a lot to learn on how to use and write this. The latter is my hope)

kurtbuilds 3y ago
Can you elaborate on why the `mixing` approach doesn't work? Specifically, if you want send bounds, doing this: trait HttpService: Send { fn fetch(&self, url: Url) -> impl Future<Output = HtmlBody> + Send; } impl HttpService for MyService { async fn fetch(&self, url: Url) -> HtmlBody { // This works, as long as `do_fetch(): Send`! self.client.do_fetch(url).await.into_body() } }
- gdcbe 3y ago
  Of course that works. But only as long as everything is always hardcoded as Send. Which is a known limitation, so no complaints. Edit: also the problem is about the method async returned future trait bounds, not the Self.
aliceryhl 3y ago
It's well known that what is being stabilized today is lacking the Send bounds stuff. In fact, there was a lot of discussion about whether they should completely block this feature until the Send bounds stuff was ready. Ultimately I think it is good that they shipped this part of the feature even though the other part isn't ready yet - Tower isn't able to use this yet, but other crates can.
- gdcbe 3y ago
  Yes Alice fully agreed. I do understand this. I just want to share my experience as a warning to others. As what is shipped is nothing less than amazing. It would be ashamed if this results to disappointment due to wrong expectations, as happened to me. I’m however very grateful for what is already there.
tmandry 3y ago
My hope is that you can use Send variants generated with the macro to reduce the typing, in cases where you need that. In the future with return type bounds, middleware would just use the local variants and only the end user needs to specify the Send or Local variant.

by gdcbe 3y ago

kurtbuilds 3y ago

Can you elaborate on why the `mixing` approach doesn't work? Specifically, if you want send bounds, doing this: trait HttpService: Send { fn fetch(&self, url: Url) -> impl Future<Output = HtmlBody> + Send; } impl HttpService for MyService { async fn fetch(&self, url: Url) -> HtmlBody { // This works, as long as `do_fetch(): Send`! self.client.do_fetch(url).await.into_body() } }

gdcbe 3y ago
Of course that works. But only as long as everything is always hardcoded as Send. Which is a known limitation, so no complaints. Edit: also the problem is about the method async returned future trait bounds, not the Self.

aliceryhl 3y ago

It's well known that what is being stabilized today is lacking the Send bounds stuff. In fact, there was a lot of discussion about whether they should completely block this feature until the Send bounds stuff was ready. Ultimately I think it is good that they shipped this part of the feature even though the other part isn't ready yet - Tower isn't able to use this yet, but other crates can.

gdcbe 3y ago
Yes Alice fully agreed. I do understand this. I just want to share my experience as a warning to others. As what is shipped is nothing less than amazing. It would be ashamed if this results to disappointment due to wrong expectations, as happened to me. I’m however very grateful for what is already there.

tmandry 3y ago

My hope is that you can use Send variants generated with the macro to reduce the typing, in cases where you need that. In the future with return type bounds, middleware would just use the local variants and only the end user needs to specify the Send or Local variant.