Shachar Langbeheim - async & FFI - not exactly a love story - Rust Linz 

Fascinating talk with a surprising conclusion. Thank you!

Great talk. On episode 160 of the ADSP podcast Sean Parent mentioned the Adobe concurrency library and work being done to make it use the “operating system native thread pool” and to have it support rust concurrently with C++. Perhaps people who found this talk interesting would be interested in that as well

Excellent talk. A lot of useful information. Thanks a lot.

So according to the description in the video, the desired functionality is to have some asynchronous task on the Java side that is rewritten using Rust to improve performance? In such a scenario, there must be an executor and a reactor on the Java side (terms from Rust), and at the same time, there must be an executor and a reactor on the Rust side to execute the rewritten task. Hmmm... If that's the implementation, then there's a basis for better performance of UDS, since it's not fundamentally different from a multi-process program. I think a better approach would be to implement a language-independent runtime, which would reduce the cost of async&ffi. However, I'm a bit skeptical that the "other-lang-async-ffi-rust" pattern will lead to performance gains, in general, asynchronous code is not compute-bound.

Great talk. But not entirely convinced that async FFI is faster than socket implementation. Are we sure that the FFI implementation wasn't the issue ? Maybe there could be a better implementation that solves this ? Or, we need an FFI for message passing than task passing ? That would be different from socket because OS won't be involved.

8:05 [slide 6] Shachar’s talk about FFI from CoreCpp: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-43Tmqn-sFsk.html

Kind of intuitive, bout still cool, thx