rust-magic-function-params VS structopt

Yes! https://github.com/alexpusch/rust-magic-function-params

An approach similar to https://github.com/alexpusch/rust-magic-function-params can be used here. Basically, define a trait and implement it on FnOnce(A) -> R, then do function.trait_method(args).

I don't know what it is called but this helped me understand how they worked a little bit. https://github.com/alexpusch/rust-magic-function-params

I've written a few backend APIs with rust and I have to disagree. Not only have the frameworks managed to get the ergonomics similar to your popular GC lang[0][1], the natural lack of shared mutable state of HTTP handlers means you very rarely have to encounter lifetimes and a lot of the language's advanced features. What's more, now when I go back to work with other languages, I can't help but notice the significant number of unit tests I'd not have had to write in Rust. It doesn't have a Rails and Django but it's an easy pick over anything at the language level.

A note on performance, Rust's the only langauge where I haven't had the need to update my unit test harnesses to `TRUNCATE` data base data instead of creating a separate db per test on PostgresSQL.

I'll also like to mention the gem that is SQLx[1]. As someone who's never been satisfied with ORMs, type checked SQL queries that auto-populate your custom types is revolutionary. With the error-prone langauge-SQL boundary covered, I was surprised just how good it can get making use of the builtin PostgreSQL features. Almost to the point that amount of effort the community's put to building great tools like Prisma.js and feel like a fool's errand (at least so for PosgreSQL).

[0]: https://github.com/alexpusch/rust-magic-function-params

[1]: https://github.com/juhaku/utoipa

[3]: lib.rs/crates/sqlx

I saw this recently. Besides that, take a look at some Axum examples particularly at Extensions and Extractors.

Hope you are aware that structopt is in maintenance mode and is merged into clap as of v3.

As I understood you need to implement a command line argument parser for that you can use clap https://github.com/clap-rs/clap or structopt https://github.com/TeXitoi/structopt.

I feel like discovering moves like this is a weakness in the ecosystem today. You can check out some of our discussion on raising visibility

Something I've been giving thought to is how to help structopt users discover that clap3 is their upgrade path. We've put notices in the structopt repo but cargo upgrade and docs.rs won't say anything. See https://github.com/TeXitoi/structopt/issues/525 for more ideas we're considering.

For myself, I have found serde.rs really useful for undertanding their derives while I've always been frustrated with finding anything in structopt's documentation, so I modeled it more off of serde. This ended up both being in structure and not being in docs.rs. I think it really was the structure that was the frustration point for me but there was interest elsewhere in moving stuff out of docs.rs.

I think it would be nice to have a comparison to clap-derive and/or structopt in the README, as that is what I expect most users would compare this to. The subcommand handling looks especially cumbersome compared to deriving on structs and enums.

However, the one place I'm a little curious to rewrite things is the CLI... every time we have to deal with cobra I long for Rust's structopt.

Have you tried https://github.com/TeXitoi/structopt ?

It is written in Rust using the structopt and swayipc crates. It is published on crates.io. The repository is hosted on GitLab. The repository is mirrored on GitHub.

I use structopt, which itself uses clap.