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 > [email protected] > https://lists.gnu.org/mailman/listinfo/gnunet-developers _______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
