In Rust, using the Option and Result types make the general flow of the application much easier to organize, make modular, and reuse.

This was a good blog post. I particularly appreciated the statement about the validate and parse function comparison: “Both of these functions check the same thing, but parseNonEmpty gives the caller access to the information it learned, while validateNonEmpty just throws it away.”

In what scenario could the first character be a newline character? I think that if-statement may be unnecessary, but I never use raw user input like you are here.

I’m not sure that you need a range when pulling the character from the input variable. Simply input[i] and input[input.len() - i - 1] should work.

Boo, just missed it.

Is this already in a crate? I’d be happy to change over from rusqlite to limbo, at least for the async functionality.

At first I was disappointed to see this, but after looking into it it looks like they weren’t using hyper as a means to migrate the project to Rust. If they’re not going to move away from C, it seems like a fair decision.

There is a market for a game engine that uses algebraic variables and geometry to guarantee purely accurate collision detection. That said, a bit of searching shows that it’s going to be much slower then current approximate approaches.

I remember Click (2006) being very sad, but I haven’t watched it in a long time.

The episode “The Sign” of Bluey, the end.