bpaf vs clap about blessed-rs HOT 9 CLOSED

My thought process on this being that bpaf seems to be close to feature parity with clap, while having faster compile times and lower binary size (see https://github.com/rosetta-rs/argparse-rosetta-rs). Which (particularly the compile times) seemed like they might be a better tradeoff for most people.

I would potentially be open to swapping the order on these two. Is there anything concrete that clap does better than bpaf?

from blessed-rs.

It was added in 027aead without details.

On reddit, I found this comment

I am considering adding bpaf to the recommendations in the "full" category, as they recently added this support.

"this" referring to UTF8 support

from blessed-rs.

From quickly perusing the derive documentation, it didn't look like it has feature parity. Feature parity also seems like a tricky aspect to judge on, as a smaller feature set with superior performance or more ergonomic API might still be preferable.

Also my impression that the site tries to provide an indication of community consensus, which IMO given the download numbers above clearly point in the direction of clap.

But IMO if you're going to mention a newer/less popular runner-up like bpaf it's hard to defend not mentioning some of the other competitors in the space like argh or gumdrop.

from blessed-rs.

While some might feel I'm biased, I find bpaf is not a good general recommendation. Initially, I had hoped it had some potential and wondered about the future of clap with it but quickly found that it will take a lot before I can seriously consider it a replacement for clap. In trivial cases, the derive works well, builds fast, and provides a small binary. For anything past that though, you need to be steeped in a Haskell mindset to figure out how things work. I at least view blessed as something that provides "safe" defaults ("no one was ever fired for buying from IBM" type defaults). serde is a good example of this compared to the other options. I see clap being like serde.

In all seriousness, the maintainer replied to a comment of mine with

Hmm... Maybe, but this naming seems more natural in Haskell. Parser is a proper Applicative you can compose, while OptionParser is just an object you can run or transform a bit, Parser is a very common name and most of them are monads or applicatives. Need to check how other libs are handling this in Rust.

Every time I say "this can't be done with bpaf", the author replies back with some non-obvious application of the available functionality.

from blessed-rs.

If you equate serde's level of blessedness with clap's, I'd certainly consider that biased. 😛 But in this particular category, I definitely think clap is the "blessed" choice at this point, and if any alternatives were to be listed I don't think bpaf would make the natural shortlist.

from blessed-rs.

Also my impression that the site tries to provide an indication of community consensus, which IMO given the download numbers above clearly point in the direction of clap.

imo its best to not run purely off of metrics but to do some editorializing as metrics won't help with "up and coming" crates compared to "this is used everywhere even if it shouldn't". I feel like it requires enough familiarity within the domain, taste, and judgement to avoid high churn.

If you equate serde with clap, I'd certainly consider that biased.

No, I do not mean to equate them generally but more specifically as being generally applicable and a safe option compared to the other choices.

from blessed-rs.

But IMO if you're going to mention a newer/less popular runner-up like bpaf it's hard to defend not mentioning some of the other competitors in the space like argh or gumdrop.

@nicoburns said on reddit

I don't think I can really recommend anything that doesn't handle non-utf8 arguments

which takes out argh and gumdrop. I can't remember which of those but at least one of them is also very opinionated on what argument formats it accepts which disqualifies it in my mind.

from blessed-rs.

imo its best to not run purely off of metrics but to do some editorializing as metrics won't help with "up and coming" crates compared to "this is used everywhere even if it shouldn't". I feel like it requires enough familiarity within the domain, taste, and judgement to avoid high churn.

I'm not saying metrics are everything. I think these are two separate points:

• If you want to mention an up-and-coming crate, it should maybe not appear first in the list
• The particular case of 12k vs 14M recent downloads strengthens my conviction in this case

from blessed-rs.

Right, I'm convinced. In particular:

• "For anything past that though, you need to be steeped in a Haskell mindset to figure out how things work."
• "Every time I say "this can't be done with bpaf", the author replies back with some non-obvious application of the available functionality."

both seem quite damning.

And 12k vs 14M is indeed a very significant difference in adoption. The number for what I thought might be a relevant comparison: once_cell vs lazy_static actually show 5M vs 4M in favour of once_cell.

I'll the swap the recommendation back to clap.

from blessed-rs.