"Are we GUI yet?" is a topic that frequently comes up within the Rust community. There are a lot of hard problems to solve, from the complexity of state management to something as easy to overlook as smooth resize. One problem I don't see discussed as often is a development and release pipeline that can handle the unique circumstances of each target platform. I met up with a bunch of application framework developers the day after RustNL to explore this problem and what can be done for it.

Winnow is a parser-combinator library for Rust and 0.5 is now out. I last wrote about the 0.3.0 release, so I'll be covering all of the releases since then.

With the release of rust 1.70, there was some surprise and frustation that unstable test features now require nightly, like all other unstable features in Rust. One of the features most affected is --format json which has been in limbo for 5 years. This drew attention to a feeling I've had: the testing story in Rust has been stagnating. I've been gathering my thoughts on this for the last 3 months and recently had some downtime between tasks so I've started to look further into this.

The tl;dr is to think of this as finding right abstractions to stabilize parts of cargo_test_support and cargo nextest.

clap v4.2.0 is now out with styling of help descriptions! See the changelog for more details.

anstream is a new take on terminal styling for Rust and will be used in the upcoming clap 4.2 release.

Quick links

It is finally time to take the wraps off where I disappeared to over the last 6 months. Besides the family leave, I've mostly been chalking this up to working on toml_edit but one particular building block took up most of that time.

I would like to introduce you to winnow, a fork of the venerable nom parser combinator library. For those that want to skip all the details, you can checkout the documentation and the migration guide and changelog.

I would link to the docs but docs.rs seems to be backed up this morning.

toml v0.6 is now out with a new parser and renderer, addressing several existing issues and ensuring compliance with the TOML 1.0 compliance tests. This was done by leveraging the toml_edit crate.

clap v4.1.0 is now out! See the changelog for more details.

We are excited to (pre-) announce clap 4.0! This release focuses on removing deprecated APIs and finishing what we couldn't do without breaking changes. For more details see the CHANGELOG (including the migration guide) and the documentation.

This release builds on work done in the 3.x releases and can be worth catching up on them:

To put all of this work into numbers:

Baseline2.34.03.0.03.2.214.0.0-rc.14.0.0
Builder API Surface174245282165 [1] [2]166
Lines of Code613,46217,30824,04420,653 [1] [3]20,839
Code size218.2 KiB487.0 KiB609.3 KiB605.5 KiB544.3 KiB [1] [4]542.6 KiB
Runtime7.529 us14.544 us14.657 us8.2478 us [5]7.6455 us

(see Methodology for more details)

Aside: Yes, those clap v2 -> v3 numbers are not good.

For Builder API Surface, it is understandable when you consider we mostly didn't remove functionality in v3 but deprecated it, removing it in v4.

Lines of Code is mostly accounted for with the merge of structopt into clap as clap_derive. We continued to have significant growth after that as we continued to develop replacement features for functionality in clap. These more general solutions take up more lines though not more code size.

For code size and runtime, one factor is that things fell through the cracks during clap v3's development. clap's development went dark for an extended period of time and went through several maintainers. This isn't to say one of the maintainers is at fault but that things get lost in hand offs. Towards the end, we double-downed on just getting out what we had and hadn't looked to see how we compared to v2.

For code size, it looks like it was a lot of small changes that added up, like changing a VecMap to a BTreeMap.

For runtime, it seems to mostly be a single feature that caused it which was removed in v4 [5].

Our plan is to give about a week window between the release-candidate and the official release to allow for collecting and processing feedback.

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