What's everyone working on this week (52/2018)?


Merry Rustmas! What are you folks up to?


I am working on developing a bloom filter served over a rest API https://github.com/abhijat/invalidator.

It works but I sort of skipped on writing any tests while quickly hacking it out so I’m adding tests now, as well as adding some benchmarks.

Might also try to make the filter distributed over multiple nodes.

A blog post I wrote here describes some of the reasoning behind this.


I am working on low level http library ( like hyper ) want to try and get better bench results and more experience :slight_smile:


This week, I’m working on a tutorial for my 2D game framework, Tetra - I’m hoping it can serve as a nice introduction to Rust gamedev, as a lot of the concepts would translate just as easily to GGEZ or Quicksilver :slight_smile:


I’ve added search to crates.rs.

It’s based on tantivy and actix. It’s pretty fast: on my machine it does 2000 searches per second.


I’m working on building a kind of android base for piston/pistoncore-graphics development on Android. I’m having trouble figuring out how to order the LostFocus event detection for when user changes app, but I got cargo-apk to work with rust 2018, so that’s a plus.


the last week I add graphql to my API example https://github.com/dancespiele/listing_people_api_actix and this week I start with a new project which call consumer. My idea is create a framework message blocker which could be used for backend applications and write code as easy as write with express.js.


I’m working on monocular which is a logic analyser with a web frontend, rust host running on a raspberry pi and a FPGA written in clash that reads all the signals.


I’ve finished documenting partial_ref and made a first release and blog post about it. It’s my attempt at a more flexible workaround for partial borrowing across functions.


I finished the component_group crate! :tada:

I spent a while iterating on the API, writing detailed docs and thoroughly testing it. The crate is small but works really well and I’m super happy with it! :smile:


I just released zeroize 0.5 - a crate for zeroing memory for use in cryptographic or other secret-keeping contexts.

This release is notable in that it’s a total rewrite: where previous versions of zeroize used FFI to bind to OS-specific APIs for securely zeroing memory, this release is now pure Rust, and leverages core::ptr::write_volatile as well as core::sync::atomic fences. This makes it simple, portable (now tested and working on wasm), and allows it to operate on all of the core Rust scalar types and slices/iterators thereof.

In doing this rewrite, I learned a lot about Rust’s memory model (or lack thereof) and the current state of Rust’s volatile semantics. I did an extensive writeup of what I learned here:



Working more on nitric - a data processing for all sort of tasks; right now, I’m implementing ECS-like component storages with arbitrary IDs.

During the process, I’ve published two new crates :smile:


Going to add CRUD operation for JSON documents, using JSON Pointer

repo: https://github.com/bnclabs/jsondata


I’m really happy to see this. I have previously tried zeroize as an alternative for clear_on_drop, where the use of FFI and lack of types supported by the Zeroize trait didn’t make it a viable one. Now that this is fixed and you don’t need a C compiler when not using nightly, which you do with clear_on_drop, I’m definitely going to try and switch to zeroize for good.


I just added 20 tags to the rs-pbrt.org web page to make it easier (for the future) to find blog posts for a certain topic (or tag). Right now there are only 5 blog post entries and I might reduce the tags while I write more posts and re-organize things, but I wanted to provide tags and had to learn how to do so using Zola.

I also started working on Subsurface Scattering (SSS), but that’s pretty early in the game and I don’t expect any exciting images anytime soon. Anyway the intermediate (between releases) documentation has already some information about e.g. the SubsurfaceMaterial and this will continue to grow …


I wrote a convenient bash function for adding crates to your Cargo.toml using fzf and cargo-edit

function csearch() {
  local file crate filtered
  crate="$(cargo search $1 --limit 100 | fzf -0 -1 | awk -F: 'BEGIN { FS="#"; } { print $1; }')"
  filtered=`echo "$crate" | awk 'BEGIN { FS=" "; } { print $1; }'`
  if [ -f $file ];
    cargo add "$filtered"
    echo $crate


Building a Rust Book to explain some of the crypto used in blockchains, but with a storyline featuring our fond friends Alice, Bob, and Eve. (btw if anyone knows how to use external crates in mdBook that would be awesome!)


It’s been a few months since I did any rust, so I’m brushing up on by building a toy project with rocket and diesel. If that goes well, I may try to use Juniper add a graphql endpoint.


I got a STM32F3DISCOVERY for Christmas so going to work through my third rust book, https://rust-embedded.github.io/book/.


Going to give a shot at porting a go project, which is a custom wrapper around an very old SOAP service that requires you to maintain a request “session” pool… each session is only valid for 15 minutes and must either have its expiry extended or properly destroyed and new one created. Request can only be made on a valid session and only one request is allowed per session.

In go I used a buffered channel, capacity of which is the number of sessions the client has contracted. Buffered channels in go can be gnarly, since if you do it wrong you can potentially block forever :hushed:

For rust I’ve not yet built anything like this so I’m excited and curious to see how implemting something like a worker pool turns out.