After demonstrating how to build block_on() and an executor, the intention was then to explain work stealing, an async mutex and channel, timers, a reactor, and finally a complete runtime... 2/12
-
-
That sounds great, but we definitely need to make sure that libraries can easily support all these various custom runtimes. At the moment there's too many different types between the different runtimes, so most libraries just get forked entirely instead.
-
I agree this is a real problem, but I also think it's not as big as is commonly believed. The solution is to use types from the futures crate instead, and when tempted to use types from a runtime, try to push that use onto the user of your library instead.
- 5 more replies
New conversation -
-
-
Sounds neat, where can we read the code?
-
I will be gathering feedback over the next week or two and publish after that.
- 1 more reply
New conversation -
-
-
If this works out, it would be a real game changer. Providing best-in-class perf tailored to the use case with a modest amount of safe code *and* ability to change runtimes from under user code to match changing perf tradeoffs would cement
#RustLang's place as premier async lang. -
With that said, this will require even better compiler UX (vulgo: error messages) to make sense of the generics soup.
Toss a coin to your @ekuber, o valley of plenty...
End of conversation
New conversation -
-
-
Super excited to read this! I've been reading through your blog posts trying to digest them with an eye towards building a custom executor for our codebase at work. We had
@Argorak in to give a training and while chatting with him he suggested this might be the best way to go.Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.