With excitement and trepidation, I'm announcing the release of clap 3.2.

With clap 3.1, we discussed the need for a more open, extensible API and clap 3.2 represents one step in that direction. With two new builder API concepts, we are able to deprecate the following concepts:

clap 3.1 is here! Clap is a CLI argument parser for Rust and the v3.1 releases focuses on API cleanup slated for clap 4.0. See the CHANGELOG for details.

clap 3.0 was in development for 4 years and though we saw comparisons to Half-life 3 in response to the release, we also saw people who cited the long gaps between breaking releases as a motivation for using it. For clap to stay relevant we feel we need to avoid the stagnation of long release cycles while keeping things smooth for the users where clap is already "good enough". The v3.1 release is a major step in trying to strike that balance.

Is adding a function in a patch release a violation of semver? Technically, yes but technical answers aren't always the right answers.

This came up in a recent discussion focused on the relevant importance of setting the minimum patch version for a dependency. Some crates go so far as to never bump their minor version, like serde.

I figured a great way to close out the year 2021 is to wrap up the long awaited clap 3.0 release!

Some major milestones along the way:

Thanks to:

tl;dr

toml_edit is a format preserving TOML crate, allowing users to modify .toml files.

Before:

cargo init Cargo.tomlcargo's Cargo.toml
toml_edit8.7us271us
toml_edit::easy20.7us634us

After:

cargo init Cargo.tomlcargo's Cargo.toml
toml_edit4.0us149us
toml_edit::easy5.0us179us

Target:

cargo init Cargo.tomlcargo's Cargo.toml
toml-rs4.7us121us

tl;dr

As part of improving the learnability of Rust, I propose:

Recently, there was an announcement for pushgen, a port of C++ transrangers to Rust with a follow up post from the author of transrangers.

Seeing the performance numbers, I was curious what the experience was like with the different techniques compared in the followup and how the performance worked out in a real world application.

liquid v0.20 resolves several planned breaking changes we've been holding off on. This doesn't make us ready for 1.0 yet but this closes the gap significantly.

liquid-rust is a rust re-implementation of the liquid template engine made popular by the jekyll static site generator.

With people reflecting on Rust in 2019 and what they want to see in 2020, error handling has come up again:

tl;dr Cache your code-gen results with the codegenrs crate.

I've been involved in the Rust community for about a year and a half now. What attracted me to Rust is that is looks like the first viable replacement for C++. It offers similar (actually better) protections than GCed languages and the full language is available in any environment, including exception-like error handling in the Windows kernel.

I went to with a coworker to PyCon this year (videos).

I recently got the chance to redo the error handling in two different crates I help maintain. For liquid, I decided to write the error types by hand rather than use something like error-chain. In the case of assert_cli, I decided to finally give failure a try.

Context: Call for Community Posts and other posts

I'll post relevant items from my old blog. If you'd like to see all the old posts, go to eopage.blogspot.com

My personal experience treating nystagmus

Trip/equipment report for the Long Star Hiking Trail

Trip/equipment report for Kings Peak in Utah