Skip to content

Instantly share code, notes, and snippets.

View cjxgm's full-sized avatar
🦧
Recovering...

Giumo Clanjor (哆啦比猫/兰威举) cjxgm

🦧
Recovering...
View GitHub Profile

Looking into the Future

futures-rs is the library which will hopefully become a shared foundation for everything async in Rust. However it's already become renowned for having a steep learning curve, even for experienced Rustaceans.

I think one of the best ways to get comfortable with using a library is to look at how it works internally: often API design can seem bizarre or impenetrable and it's only when you put yourself in the shoes of the library author that you can really understand why it was designed that way.

In this post I'll try to put down on "paper" my understanding of how futures work and I'll aim to do it in a visual way. I'm going to assume you're already somewhat familiar with Rust and why futures are a useful tool to have at one's disposal.

For most of this post I'll be talking about how things work today (as of September 2017). At the end I'll touch on what's being proposed next and also make a case for some of the changes I'd like to see.

If you're interested in learning more ab

This work, excluding the Arch Linux logo, is made available under CC0: https://creativecommons.org/publicdomain/zero/1.0/
@haosdent
haosdent / x_layout.keylayout
Last active September 12, 2024 23:35
Mac OS X Keyboard layout file, works in 10.11
<?xml version="1.1" encoding="UTF-8"?>
<!DOCTYPE keyboard SYSTEM "file://localhost/System/Library/DTDs/KeyboardLayout.dtd">
<!--
Data generated Wed Mar 23 01:35:41 2022
Generated by kluchrtoxml_64 build 203
-->
<!--Last edited by Ukelele version 351 on 2022-03-23 at 01:45 (GMT+8)-->
@m2ym
m2ym / SplayTree.hs
Created December 7, 2012 10:34
Toy Splay Tree in Haskell
import Data.Maybe (isJust)
data Tree a = Leaf | Node (Tree a) a (Tree a)
replace :: a -> Tree a -> Tree a
replace a Leaf = Node Leaf a Leaf
replace a (Node l _ r) = Node l a r
rotateR :: Tree a -> Tree a
rotateR (Node (Node x a y) b z) = Node x a (Node y b z)
@datagrok
datagrok / git-branch-simplify.md
Last active April 16, 2024 17:26
How to simplify the graph produced by git log --graph

Ideas for improvements to git log --graph

I will maybe someday get around to dusting off my C and making these changes myself unless someone else does it first.

Make the graph for --topo-order less wiggly

Imagine a long-running development branch periodically merges from master. The git log --graph --all --topo-order is not as simple as it could be, as of git version 1.7.10.4.

It doesn't seem like a big deal in this example, but when you're trying to follow the history trails in ASCII and you've got several different branches displayed at once, it gets difficult quickly.