Uh oh!
There was an error while loading. Please reload this page.
async support - #106
Conversation
davidbarsky
commented
May 10, 2019
@nappa85: Thanks for opening this! I think allowing folks to write async Lambda functions is a good idea, but given the upcoming stabilization of async/await and std::future, I was thinking of introducing a clean break and enforcing async/await first: https://paper.dropbox.com/doc/Lambda-Runtime-for-Rust-0.3--Ac2u75PLCibbXervTP2Rv5z_AQ-jLrDOiKk815YyIHLWva7M. Any thoughts? |
softprops
commented
May 11, 2019
The vision looks super dope! What I like about this pull is its relatively transparent for users to upgrade to the next version of the interface in this pull returning something that implements IntoFuture which gets the best of both worlds because todays Result interface should just work in most cases. That enables new future returning funcs and for sync funcs it should "just work" and no added syntactic cost. I think the vision in the linked document could be possible even with this implementation as a graduating step. What I really liked in the doc was that it touched on a more painful part of todays interface, a less strict error representation! Satisfying HandlerError types have been a much more economic pain point than block_on calls. I'm a fan of where the async/await syntax is going but I'm an even bigger fan of using a compromise that works on stable Rust today ;) |
davidbarsky
commented
May 11, 2019
via email
Oh, I’m really sorry! I’m in favor of merging this change, and I have no idea why I said “introducing async/await first!” I must’ve not been paying attention when typing. Really sorry! …________________________________
From: Doug Tangren <notifications@github.com>
Sent: Friday, May 10, 2019 11:06 PM
To: awslabs/aws-lambda-rust-runtime
Cc: David Barsky; Comment
Subject: Re: [awslabs/aws-lambda-rust-runtime] async support (#106)
The vision looks super dope!
What I like about this pull is its relatively transparent for users to upgrade to the next version of the interface in this pull returning something that implements IntoFuture which gets the best of both worlds because todays Result interface should just work in most cases. That enables new future returning funcs and for sync funcs it should "just work" and no added syntactic cost.
I think the vision in the linked document could be possible even with this implementation as a graduating step. What I really liked in the doc was that it touched on a more painful part of todays interface, a less strict error representation! Satisfying HandlerError types have been a much more economic pain point than block_on calls.
I'm a fan of where the async/await syntax is going but I'm an even bigger fan of using a compromise that works on stable Rust today ;)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#106 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAPY2PWDOFRPV5LKA2WFGW3PUYZ27ANCNFSM4HMBXCWQ>. |
nappa85
commented
May 11, 2019
Sorry for late reply. |
Uh oh!
There was an error while loading. Please reload this page.
davidbarsky
left a comment
There was a problem hiding this comment.
Thanks for this! Can those small nits be addressed and then we can merge/release?
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
nappa85
commented
May 28, 2019
Hello, sorry to bother you all... |
davidbarsky
commented
May 28, 2019
via email
Not a bother! I don’t have any additional concerns merging this and would be happy if @sapessi or @softprops don’t have any concerns. …________________________________
From: Marco Napetti <notifications@github.com>
Sent: Tuesday, May 28, 2019 6:09 AM
To: awslabs/aws-lambda-rust-runtime
Cc: David Barsky; Comment
Subject: Re: [awslabs/aws-lambda-rust-runtime] async support (#106)
Hello, sorry to bother you all...
Are there still open tasks blocking this merge?
Thank you
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#106>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAPY2PXCPY3IRD24EWP2GCDPXUAHNANCNFSM4HMBXCWQ>. |
softprops
commented
May 29, 2019
I'm feelin it |
nappa85
commented
Jun 28, 2019
Bump |
lvicentesanchez
commented
Sep 9, 2019
hi! what's the status of this PR? I would really like to start using async lambdas. |
mies
commented
Nov 6, 2019
any update on this @davidbarsky@nappa85 ? |
sbditto85
commented
Dec 17, 2019
bump. update? |
drusellers
commented
May 16, 2020
Just checking in. :) |
davidbarsky
commented
May 16, 2020
You should be able to pull from the master branch and take this for a spin. It doesn’t suck. |
softprops
commented
May 26, 2020
I think this can be closed now |
brainstorm
commented
Jul 14, 2020
Yes, this can be closed, async works very well on rust-lambda for a while now 🚀 |
coltonweaver
commented
Jan 25, 2021
Going to close this PR as it seems all is well here! |
Issue #14
The main loop has been converted into a future::LoopFn, who takes ownership on the Runtime.
Now it is possible to use async code inside lambdas.
By submitting this pull request