I just updated an old project that used Hyper 0.10 (back when it still had a synchronous API) to use the Reqwest crate instead (which is the new recommended synchronous HTTP library). That change added :shock_kosaki: 90 :shock_kosaki: new dependencies.

Are we NPM yet?

Me, wanting to free some resources by eagerly closing a database connection in a program:


That doesn't look quite so innocent as I had intended.

I was recently thinking that , despite not always being as comfortable as higher-level languages, has both the technology and the momentum to provide an efficient and true mixed client-server web development framework, similar to OCaml's Ocsigen[1]. And lo and behold, Sauron[2], a crate doing exactly that, is now on HN. Here's hoping that this concept catches on and matures.

1. ocsigen.org/
2. github.com/ivanceras/sauron

I've resisted for a while, but I finally joined the hipster culture of left-pad-esque microlibraries in .

That is to say, I just published my first crate: crates.io/crates/multisock

gotcha: `u16::max_value as u64` does not show a warning or error, but is almost certainly not what you want.

I kinda understand the difference between sync/async programming, threading vs. non-blocking I/O, etc. But I don't really understand the current trend of providing a synchronous interface ([cg]oroutines, async/await) on top of an asynchronous system. If you want synchronous code, why not use actual threads? In particular, what is the appeal of 's from a programming perspective? I realize that threads may have a bit higher overhead, but is that the *only* reason to use tokio?

Oh crap. I'm using 's Rayon crate to modify each entry in a BTreeMap in parallel using a mutable iterator. Pretty easy, no problems there. But that operation can take a while, and now I want to periodically flush the contents of that BTreeMap to disk while it's working - so we don't lose much progress if the program is interrupted halfway. But that flush operation needs to be able to read the entire BTreeMap, which Rust's type system helpfully prevents.

And down the rabbit hole I go...

And behold said "horrible Rust hack".

: "You can only safely construct a DST by coercing struct with a size known at compile time"
Me: "Behold my copy-paste power!"

It goes on for 1000 lines. I really ought to be expelled from the programming community for this abomination.

It's funny to see how my code is evolving the more I use it. Previously:

match some_option {
None => (),
Some(x) => {

After realizing that Option implements IntoIterator:

for x in some_option {

I'm genuinely impressed by the Rayon crate.

I wanted to do parallel recursive tree traversal and thought of a few algorithms to do so. A naive thread pool wouldn't work: With a bounded queue it would deadlock, with an unbounded queue it would use too much memory. This requires more coordination between threads to do the work efficiently. I was all ready to implement that complexity myself, but then I found that Rayon uses work stealing. That solves the problem entirely and elegantly.


Welcome to your niu world ! We are a cute and loving international community O(≧▽≦)O !