Re: [GNUnet-developers] [GSoC] Question on "Rust implementation of GNUnet utils" project

[Jeff Burdges]

I've learned slightly more about our asynchronous IO options.  I'll give
some notes below, but the short version is :

We should *first* trying using gj for a Rust implementation of GNUnet
utils because it's actually the most restrictive callback-like event
loop.  It'll be easier to migrate from gj to anything else. 

Jeff



Notes :


There are interesting features of both eventual_io vs gj : 
- Eventual provides the abstraction layer that Christian and Andrew
expressed an interest in. 
- Cap'n proto has an interesting RPC facility built on gj.

And they differ with how they interact with threads :
- Eventual imposes Send bounds frequently, so that types can move
between threads.  As it better abstracts thread pools, but you must use
Arc<> types lots.
- Anywhere that eventual needs an Arc<>, gj uses its non Send cousin an
Rc<>.  

It follows gj cannot interact as flexibly with threads, but really Rc<>
should be viewed as "more thread safe" because you're forbidden from
sharing them between threads at all.  In particular, it's easier to
migrate code based on gj over to eventual that the reverse. 

It's easier to make eventual code run on top of another thing, like say
a state machine, but that's unlikely.  And porting gj code to eventual
code appears really trivial if one wishes to do is that way.  And gj's
restrictions would help if making the transition more manually.

We should hold off starting the Cap'n proto RPC conversation since it
does not pertain to existing GNUnet services, but it add extremely
interesting long-term options. 

There is a good chance Rust gains higher-kinded types within the next
couple years, which should enable eventual to be polymorphic over
bounds, and might precipitate a merger of eventual and gj.  

> Futures 
> https://github.com/carllerche/eventual_io
> - No docs, but eventual has docs :
>   https://carllerche.github.io/eventual/eventual/index.html
> - Three contributors, seven if you consider eventual.  By mio guy

> Promises 
> https://github.com/dwrensha/gj 
> - Some docs : http://docs.capnproto-rust.org/gj/index.html
> - Just one contributor.  He works at Sandstorm.io


We should probably avoid coroutines, meaning no mioco, since we should
not need that messy extra flexibility for GNUnet's proposes.  Also,
Christian expressed reservations about building on APIs significantly
more powerful than necessary.

> Coroutines 
> https://github.com/dpc/mioco
> - Most examples by far.  Okay docs :
>   http://dpc.pw/mioco/mioco/index.html
> - Nine contributors, quite active.


There are folks singing the praises of state machines, like
https://engineering.shopify.com/17488160-why-developers-should-be-force-fed-state-machines
And they do have greater advantages in Rust, like helping eliminate even
Rc<> wrappers.  I suspect however that our code in GNUnet is largely
higher level than where they really shine. 

> State Machine
> https://github.com/tailhook/rotor
> - Best docs by far, including design blog, but fewer examples :
>   https://tailhook.github.io/rotor/rotor/index.html
> - Eight contributors, quite active.

signature.asc
Description: This is a digitally signed message part