I recently released papaya , a fast and feature-complete concurrent hash table for Rust. In this post I want to dive into the design and research that went into creating it, as well as why you might consider using it over existing solutions. If you're looking for an overview of papaya, you might find it more useful to consult the documentation . Philosophy Concurrent hash tables are a well…
I've found that one of the best ways to understand a new concept is to start from the very beginning. Start from a place where it doesn't exist yet and recreate it yourself, learning in the process not just how it works, but why it was designed the way it was. This isn't a practical guide to async, but hopefully some of the background knowledge it covers will help you think about…
The ideas laid out in this crate have since been implemented in the boxcar crate. A while back while researching for seize , I came across a cool little idea for a concurrent vector in this paper . I'm not sure where the idea originated from, but it's also the basis for the concurrent vector in Intel TBB . Introduction Supporting remove in a concurrent setting is a particularly difficult…
There are a handful of concurrent algorithms, most famously solutions to the ABA problem , that require 128-bit atomics. Unfortunately, the story around 128-bit atomics hasn't been great, but recently both compilers and CPU manufacturers have been making strides toward full-fledged support. x86 cmpxchg16b serves as the double-word compare-and-swap instruction on x86, and exists on just about…
Async Rust is taking over, quickly becoming the default for libraries that do any sort of I/O. While async is incredibly useful for a large number of applications and enables patterns that simply cannot be expressed in blocking code, it does come with a certain amount of added complexity. Because of this, there is still a large audience for blocking crates. ureq for example, a blocking HTTP…
I wrote a post a while back about how I think Rust's async fn syntax hiding the returned Future type was a mistake. I essentially proposed changing this: async fn foo (x: &str , y: &str ) -> usize { /* ... */ } To this: async fn foo (x: &str , y: &str ) -> impl Future<Output = usize > + 'in { /* ... */ } This solves the problem of adding Send/Sync bounds to async…
Hidden inside std::collections::hash_map is a struct called RandomState . It's job is to initialize a DefaultHasher with a random seed for use in a HashMap . It turns out that if you create a random DefaultHasher and extract the final hash without actually hashing anything, you get a random number. fn rand () -> u64 { RandomState::new(). build_hasher (). finish () } fn main () { for _ in 0 ..…
After thinking about the async fn in traits problem for a while, I've come to the conclusion that the syntax Rust chose for async fn is the wrong one. Specifically, the fact that the returned future type is hidden is quite limiting: // this really returns an `impl Future<Output = usize>`, but that's hidden async fn foo () -> usize { 1 } I propose that we should explicitly write out…
A lot of thanks goes to fasterthanlime for inspiring this article with A half-hour to learn Rust . I thought I'd try something similar, but instead of Rust, this article will try provide an overview of Go in twenty minutes. Ready? Go! Packages Every Go program is made up of packages. Programs start by running the main function in the main package. package main func main () { // ...…
I recently had to migrate a Rails app from Postgres to MongoDB. The process wasn't that straightforward, so I thought I'd share some tips I learned along the way. Note that this post does not cover data migration. See pg2mongo and the official MongoDB migration guide for more information. Removing Active Record The officially supported MongoDB driver for Rails is Mongoid , which aims to…