New week, new Rust. What are you folks up to?
Giving Serde the ability to derive Serialize and Deserialize implementations for types in other people’s crates!
Working on an implementation for Elasticsearch’s bulk API in
serde 1.0 comes along with zero-copy deserialisation we’ll be able to really efficiently deserialise large bulk responses where you only care about operations that failed. It just needs some documentation cleanups and a sanity check and it’ll be good to go
I am working on a distributed system and need to set up secure channels between servers. To do that I’m playing with TLS client auth using tokio-rustls. I ran into some blocks but they were because my certs were not proper*.
I learned a bunch trying to figure out the issues so that was not a waste.
Cool! Will that be some variant of the new-type solution we’ve got now?
Done extracting the common testing & benchmarking code of my lock-free synchronization primitives into a separate crate, testbench. Nothing special for now, maybe I’ll grow it into something more complete as the need/demand arises.
After that, I took advantage of an annoying work meeting to start porting a Monte Carlo simulation to Rust. This simulation is a piece of very old code (dating back from the FORTRAN 77 era), which we like to use at work as a test bed for new programming languages and parallel programming tools for scientific computing, because it’s simple enough to be easily ported in a week, but complex enough for the porting process to reveal interesting issues.
I’ll try to do a quick write-up about the porting experience here once I’m done. Overall, Rust worked pretty well for some things (lightweight syntax, immutability by default…), but less well for others (mathematical function syntax, array initialization…).
I’m slowly cleaning and pushing some Linux-containers related code that I had lying around locally, mostly written to learn and experiment with serde and tokio:
Working on an XMPP library based on tokio https://github.com/Freyskeyd/xmpp-rs
It’s a work in progress but I have something working I can:
- Negociate PLAIN auth over tls
- Send first presence
- Respond to incoming message
- Send ping request and read ping response
A lot of work to do (doc, api improvment and XEP) but it’s a pleasure to work on it.
I’m finalizing a simple Kernel tuning library for OpenCL - https://github.com/botev/k_tune. It is more or less based on CLTune c++ repo. As a relatively newbie in Rust and interest in OpenCL I thought of doing this for optimizing specifically a GEMM kernel.
I’m writing documentation for cpp_to_rust and rust_qt crates. I hope to bring them to an alpha release soon.
I’m working on adding gzip support to the deflate crate, a big step closer to making it a decent fully rust-implemented replacement for the (encoding part of the) C library-backed flate2.
Finishing up writing tests for
uom and then publishing a new version. Tests written last week found an
impl Sub that used
+ instead of
I’m working to move cernan’s prometheus interface from experimental status into something production-worthy. A lot of that is driven by the discovered behaviour of Prometheus, especially with regard to the constraints it puts on time series ingestion. Built a special purpose aggregator to handle those constraints, plus a suite of quickcheck tests.
Trying to give a GUI to my Lighting Control System: a program to control DMX lines. I’m using the gtk-rs crate.
I’ve slowly been integrating the borrow visualizar changes into the compiler. Integration here is really, really slow. I can only put in a couple days a week (still in interview mode, but almost over!), and the changes I have to do take hours to compile. I need to change a crate on crates.io that’s used by the compiler, recompile the compiler to stage 3 so I can get the dynamic libraries needed to build RLS with all the necessary changes, and then build RLS. Just compiling all of that takes close to 4 hours on my current hardware. I have yet to work on the visualization portion for this. The current code I had performs horribly and is a giant mess. It was just a mashup of trying to understand how vscode and atom render things. Once interviews are done, I’ll definitely build a desktop dedicated to improving compile times. That should dramatically speed up this effort.
Btw, if anyone knows how I can get the compiler’s dynamic libraries without having to go all the way to stage 3, I would be so grateful .