toml v0.9
is a near-complete rewrite with dramatic performance improvements, no_std support, and many other improvements.
This is where I've disappeared to over the last 3 months, trying to wrap up a years-old experiment that has been "almost done" for these last 3 months, with use case after use case building up encouraging me to finish this up rather than my regularly scheduled Cargo work.
"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 frustration
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.
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.
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:
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:
Arg::allow_invalid_utf8
Arg::validator, Arg::validator_os
Arg::forbid_empty_values
Arg::possible_values
Arg::max_occurrences
Arg::multiple_occurrences
Command::args_override_self
AppSettings::NoAutoVersion
AppSettings::NoHelpVersion
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!
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:
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.