byteorder VS docopt.rs

Ditto, I guess? :P (But obviously with the position on the Unlicense flipped.)

To address your indictment head-on: you suggesting the 0BSD as a better alternative is really missing my point. The 0BSD is not an alternative for my use case. The Unlicense is one of the very few overt "political" acts that I inject into the software I produce. Its purpose is to make a statement. The 0BSD doesn't do that IMO, so it's not actually an alternative that meets my advocacy goal.

You and Rick Moen seem to have the same apparent blind spot for this. See my conversation with him that started here (which might also clarify some aspects of my own position): https://github.com/docopt/docopt.rs/issues/1#issuecomment-42...

And finally, note that my dual licensing scheme is exactly a response to the "problems pointed out by quite a few people": https://github.com/BurntSushi/byteorder/issues/26

If you want something more convenient and higher-level, you can (and frankly should) use the byteorder crate, which has a bunch of structures and traits to make dealing with byte order simpler. The only thing it's missing is the ability to adapt (wrap) a stream but that's about it.

Of course in C you can get a pointer to the value and iterate over the raw bytes in memory to print them one at a time, but that's above and beyond just using %x. The easiest way to do this in Rust that I can think of is by using the byteorder crate.

If you're reading and writing numbers a lot, consider using byteorder. Otherwise, you can see how read_u8 and write_u8 are implemented.

Consider using clap or possibly structopt instead.

It's a lovely way to internalize the CLI argument cultural norms, decrease confusing and verbose argument parsing, make argument parsing work-free for the developer, and make argument parsing a copy-paste across languages. There's no greater pleasure than iteratively adding options to your program by just adding a line of text

-n, --new-option Do something new

I honestly think making a docopt parser is just very hard, which may limit its future prospects.

[the docopt rust repo.]: https://github.com/docopt/docopt.rs

Ditto, I guess? :P (But obviously with the position on the Unlicense flipped.)

To address your indictment head-on: you suggesting the 0BSD as a better alternative is really missing my point. The 0BSD is not an alternative for my use case. The Unlicense is one of the very few overt "political" acts that I inject into the software I produce. Its purpose is to make a statement. The 0BSD doesn't do that IMO, so it's not actually an alternative that meets my advocacy goal.

You and Rick Moen seem to have the same apparent blind spot for this. See my conversation with him that started here (which might also clarify some aspects of my own position): https://github.com/docopt/docopt.rs/issues/1#issuecomment-42...

And finally, note that my dual licensing scheme is exactly a response to the "problems pointed out by quite a few people": https://github.com/BurntSushi/byteorder/issues/26

I like Docopt for quick scripts, used it both in Python and Rust projects. It is quite unflexible though.

The Rust Docopt implementation¹ was deprecated this year, which is probably good because clap v3 (https://github.com/clap-rs/clap) is so awesome. In a project of mine (tealdeer), I noticed that docopt.rs was responsible for the huge majority of CPU instructions when running the binary: https://github.com/dbrgn/tealdeer/issues/106#issuecomment-59... I then switched² to clap and shaved off almost a megabyte from the release binary³. Performance improved as well, time required for rendering a tldr page went down from ~15.9 ms to ~12.4 ms⁴. With the migration, we also managed to reduce a lot of custom validation logic and move this logic into the derive macro attributes.

¹ https://github.com/docopt/docopt.rs