[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNUnet-developers] [GSoC] Question on "Rust implementation of GNUne
From: |
Kelong Cong |
Subject: |
Re: [GNUnet-developers] [GSoC] Question on "Rust implementation of GNUnet utils" project |
Date: |
Mon, 25 Apr 2016 00:06:31 +0200 |
Some of you may already know, but I've been selected to participate in
GSoC. So I'm looking forward to working with the team this summer!
>From now until 23rd of May is the community bounding period. Thus I'm
thinking of doing the following to prepare. Please let me know if I
should add anything.
- Become more proficient in Rust, possibly by choosing Rust for some of
my upcoming university assignments.
- Learn more about GNUnet, esppecially the parts that are relevant to
GSoC.
There are also some things that I'd like to clarify.
- Is it confirmed that we'll use gj going forward?
- What's the development process going to be like? Is it making pull
requests on the gnunet-rs repository?
Kelong
On Thu, 2016-04-14 at 15:25 +0200, Jeff Burdges wrote:
> 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-for
> ce-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.
>
> _______________________________________________
> GNUnet-developers mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnunet-developers