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

Async programming in Rust isn't a simple affair when running a pure-rust application. Unsurprisingly, when trying to combine Rust with another language, and expose async interfaces that cross the language barrier, there are plenty of potential mistakes to make. In this talk we'll discuss some of the pitfalls awaiting those who try to cross the language barrier.

[@Roibarkan]

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

[@zohnannor]

Fascinating talk with a surprising conclusion. Thank you!

[@Vagelis_Prokopiou]

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

[@avinashthakur80]

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.

[@asontehunsthanshhl]

Yeah I was thinking the same thing. I don't doubt sockets might be better sometimes. But I've never found FFI to be too slow for my use. FFI is also cross platform

[@ericchu6633]

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.

[@Roibarkan]

8:05 [slide 6] Shachar’s talk about FFI from CoreCpp: ua-cam.com/video/43Tmqn-sFsk/v-deo.html

[@linkernick5379]

Good reference (count! 😊), thanks

[@TheInspctrcat]

Kind of intuitive, bout still cool, thx