What's everyone working on this week (13/2017)?


New week, new Rust! What are you folks up to?


Working on zero-copy deserialization support for Serde.

#[derive(Deserialize, Debug)]
struct S<'a> {
    // borrowed from the input
    a: &'a str,

    // copied from the input
    b: String,

let j = r#" {"a":"A", "b":"B"} "#;
let s: S = serde_json::from_str(j)?;
println!("{:?}", s);


Google Code Jam 2017 starts pretty soon, so I decided to write gcj-helper, a helper library for writing solutions, and a Cargo template that’s set up to use it. It’s more-or-less usable right now, but there’s still work to be done; for 0.3.0 I want to refine the API, clean up the internals, and (the big one) enable test cases to run in parallel as an opt-in feature.


Back to playing with Rust-C# interop using C#'s new Span/Buffer APIs. It’s also a good opportunity to use the cargo-nuget tool I wrote properly and make sure it works nicely. So far so good.

Working on the C# code I really miss immutability, move semantics, lifetimes and zero-cost abstractions. Writing really efficient and safe C# is actually very hard.


Used the opportunity of a work trip to have a go at developing a multi-consumer variant of my triple buffering algorithm. It’s funny how much elegance, robustness and simplicity is lost by just combining the following three considerations:

  • Consumers cannot individually decide to liberate memory without communication anymore (other consumers may still be looking at it)
  • In general, the number of consumers is not known in advance
  • In this specific implementation, I tried to keep the synchronization self-contained and robust against panics, which surprisingly enough turns out to rule out many popular lock-free designs

Temporary conclusion: whenever you can nail your thread synchronization problem down to a one-to-one communication channel, do use dedicated SPMC primitives. They may seem like an unnecessary limited, duplicate version of the more general primitives, but this problem simplification really allows for tremendous implementation improvements, leading to better performance and robustness guarantees.

I’ll try to discuss this crate a bit more here when I find the time.


Just arrived in the Rust community and happy to have joined you guys. I’m Learning with “The Book” at the moment.

I’m a big fan of learning with flashcards and I’m creating a list of questions / short exercises based on “The Book” to help beginners like me remember the theory and repeat their practice.

If that sounds interesting to you, I’ll share my flashcards once they are ready!


This week I published my first crate: https://crates.io/crates/scarecrow

Just a basic neural networks library. Nothing much really and certainly not fit for any type of “production” use. Was an excuse to write some Rust and to try a different approach to the layer implementation.

Having previously written the equivalent code in C and C++ (with Python wrappers for both) I found it a really pleasant experience.


Started work on a scripting DSL (lichen) for dialogue graphs, to be used in games. The idea is to easily formulate logic and control flow of the graph based on requisites being met. I am almost done finalizing syntax, next step is to provide a tidy way to pull this data from a rust project.

example node:

root  # name of node
    unequipped !some_item  # local binding to if a property exists/is true
    has_weight some_weight < 5.0  # bind value from this logic
    some_comp:any unequipped has_weight  # composite type that is bound when any are true

    if unequipped "you're looking for something?"  # emit when unequipped is true/exists

    if all "welcome, \nlook around"  # emit response when all non-composites are true
;  # ends node block

Looking for any kind of feedback!

Have a great day


I’ve wondered if I can put the entire content of my hard drive in a single BTreeMap, and I could! I wrote a file deduplication utility:


I needed an expect-like crate and now I’m creating one :slight_smile:

Currently my crate takes the stdin, stdout, and stderr pipes of a child process and encapsulates them in an Interaction struct. Interaction contains the pipes and all associated information (last_read_bytes, last_send_timestamp, etc…). It also implements methods to send strings and wait for specific strings (e.g. send command and wait for command line prompt).

I want to expand it to have regex and timeout related functionality (e.g. wait for stdout to stop sending for some duration).

It’s really hard to appreciate how much work goes into common tools until you try to make them yourself.


I’m working on translating my fac build tool from C into rust.

The first and hard step is dealing with my bigbro library that uses ptrace to track file accesses of commands in order to determine dependencies. I’m not planning on translating all this low-level C code into rust (yet, anyhow), but do want to put a nice wrapper on it, which turns out to be challenging. I had hoped not to duplicate the code in std::process, but that is seeming unavoidable. :frowning:

Oh, and I’m starting teaching my spring quarter of classes this coming week, so development will probably halt…


I’m working on a program to control DMX lines of lights. Now I’m trying to get a basic working GUI in Gtk+ with gtk-rs.
My project is hosted here https://savannah.nongnu.org/projects/lcs/ if anyone is interested to contribute.


I just submitted my first two pull requests to rust-lang/rust.

I’m going to be a real contributer someday.


Oh, I’m also working on my shell_cmds port. Porting Apple’s utilities like echo, sleep, tee, etc. to Rust.


Working on a project to compile any configuration file from a single core language. Using Nom for parsing and loving it.


PSA: the thread for the current week is What's everyone working on this week (14/2017)?


Both pull requests were accepted! :slight_smile: