4·
12 days agoThis, and similar posts discussing the same subject, seem to fail to realize that you can trivially implement your own back-off strategy using Mutex::try_lock(). This can have significant performance implications in use-cases where absolute low latency is not required.
I rarely see this get mentioned, although I think I did see it once or twice.
A shout out to the spin crate too, which has a lot of options that may interest people explicitly supported/exposed. It also supports no_std which can be immensely useful in some use-cases.
The most relevant part of the curl project is the library, not the CLI tool. And its biggest advantages in addition to universal availability is support for many protocols other than HTTP, flexible interface(s), two useful well-documented and largely stable APIs (one wraps the other for easy use), multiple TLS/SSL back-end support, and finally, the complete(ish) HTTP protocol support. But that last one alone is not that big of a deal.
libcurl’s implementation even uses external libraries for both HTTP2 and HTTP3 for framing. It uses an external library for QUIC transport support too. Meanwhile, many other independent language implementations for HTTP exist that range from serviceable to complete. Be it Python, Go, Rust, or many others, you usually get a “native” option you could/should use. Gone are the days of bad old PHP. Hell, even some WIP languages add usable native implementations sometimes as a part of their standard libraries, likeinko.Within the Rust ecosystem, you’re fully covered by
hyper. Even very obscure HTTP features like obsolete HTTP1 multi-line headers are supported (you have to enable this one explicitly). And I only know this because I had the fortunate circumstance of coming across a server that used these (It was an educational, if interesting, couple of afternoon hours).