[pimeys]

Did you try to use an executor that can drive the new futures? The ability to use &self in an async context is so much nicer than playing around with Arc with things that really don't need one.

Also very happy to not being forced to write .map_err ever again.

[mmastrac]

We're in a tricky spot with our async code because we need to interop with both Android JNI, Objective C threads, and some diagnostics code that uses tokio/websockets. For the first pass there was a lot of "let's get this working with a modern executor and make it perfect later".

When we get some spare bandwidth we'll definitely see if we can get some extra productivity out of using &self. So much of our existing futures code is either self-less or uses some macro code to generate glue to allow us to use Arc-typed self - this is to allow a bunch of async core code to interop with these async platform drivers.

Been on a crash course getting better at architecting Rust programs for nine months. Luckily the Rust ecosystem and toolchain is getting even more amazing each time around so we can justify some work to refactor and try new approaches.

[pimeys]

Do you have experience doing async ffi to other runtimes from Rust? Such as passing down futures from Rust to JavaScript or Java so you can use them from their context. I'd love to read a blog post about that subject...

[mmastrac]

I can definitely talk about how we did it - maybe see if we can get something up on our blog.

Our current approach-du-jure uses callback handles in combination with channels to let the ffi code trigger a real rust future's completion. This has worked reasonably well, but I'm sure we'll experiment with a few other patterns.

We don't specifically interface with Java Futures (no particular reason other than it hasn't seemed necessary to add that complexity), but that would be a pretty cool library to build on top of the existing Rust jni crate.

One thing I'd like to pass by the Rust community is our internal "teleporter" that allows you to borrow an object mutably on one thread and then "teleport" an immutable ref to that object to any other thread using only a u64 handle (with obviously huge unsafe flags). This has been very handy for some of our async ffi work.

I'm hoping to get a few more Rustaceans onboard (aggressively hiring!) over the next few months so we can focus more deeply on some of these interesting problems.

[pjmlp]

If your Java usage is constrained to Android there is a JNI workaround that many NDK folks tend to use.

Instead of doing JNI calls, send Android messages between NDK and Framework threads.

There is the setup of MessageHandler on both sides, but long term they are more productive than JNI boilerplate.

[mmastrac]

Interesting - do you mean using the Android handler/message infrastructure? I hadn't considered that at all. Do you have any references?

[pjmlp]

Yes.

One example would be SDL, although they use a mix of JNI and messages (search for SDLCommandHandler).

http://hg.libsdl.org/SDL/file/abb47c384db3/android-project/a...

http://hg.libsdl.org/SDL/file/abb47c384db3/src/core/android/...

EDIT: Sorry forgot about the C side (counterpart is Android_JNI_SendMessage).

[samcday]

> One thing I'd like to pass by the Rust community is our internal "teleporter" that allows you to borrow an object mutably on one thread and then "teleport" an immutable ref to that object to any other thread using only a u64 handle (with obviously huge unsafe flags). This has been very handy for some of our async ffi work.

Would love to see a blog post (or better yet, library!) for this - sounds interesting!