Unsafe at Any Speed: Tradeoffs and Values in the Rust Ecosystem

So just ignore the async use cases? Or force tokio or similar to support it?

My biggest pain point so far is channels, I like them in go because they are straight forward to use, allow concurrency, aren't a minefield of problems, and are easy to reason with. I wanted to scan N directories (in parallel) -> encrypt and checksum in (parallel) -> queue files for upload. With go channels it's straight forward.

I was looking for MPMC (like go channels) to allow multiple producers to enqueue and multiple consumers to dequeue. Rust doesn't do it and tokio doesn't do it. I could use crossbeam[0], flume[1], or async[2]. Not sure what limitations those have and what if any limitations in compatibilities with other crates I need will be.

[0] https://docs.rs/crossbeam/latest/crossbeam/channel/index.htm...

[1] https://docs.rs/flume/latest/flume/

[2] https://docs.rs/async-channel/latest/async_channel/

Yeah, it seems to me like the author just wants a simple HTTP client for Rust that prioritizes simplicity over raw performance and is unhappy with the fact that reqwest isn't that. Though as developers we often wish it were otherwise, given a choice between implementation simplicity and performance most people will choose the latter (as long as correctness isn't sacrificed). So that's why reqwest is more popular and is the first choice that appears when searching for [rust http client] on Google.

Thankfully, ureq exists for those who prefer implementation simplicity, and that's what the author should probably choose.

There’s a small message contained in that unnecessarily long post - that maybe a popular library used for HTTP in Rust could use less unsafe.

There was no need for this half mocking, half condescending tone. If the author wanted an explanation for a technical decision, they could open an issue and have a conversation like an adult. Instead we’re left with their speculation that leads nowhere. They cry about the existence of some unsafe code, but don’t actually put in the effort to figure out if it can lead to a real problem like unsoundness. And somehow the title implies that they’re saying something profound about the entire rust ecosystem when they just looked at one library. It’s just innuendo, as far as I could tell.

Here’s a post by the maintainer of hyper about what they accomplished in 2023 and what they hope to accomplish in 2024 - https://seanmonstar.com/blog/2023-in-review/

If this work interests you, or you depend on hyper in production like many companies do, then consider sponsoring them! Or maybe you could give back to the commons by submitting PRs that fix issues you’ve found. Or even a good bug report would be appreciated.

But not this kind of article. This article helps no one and does nothing constructive. We all benefit from the work that open source maintainers put in. They have it hard enough without having to read low effort posts trashing their work. Be better.

> If the author wanted an explanation for a technical decision, they could open an issue and have a conversation like an adult.

Opening an issue comes across as a whole lot more aggressive to me. That implies that they owe you an explanation or you want them to change their code.

> They cry about the existence of some unsafe code, but don’t actually put in the effort to figure out if it can lead to a real problem like unsoundness.

unsafe might as well be unsound. The key benefit of Rust is supposed to be better memory safety than C; if everything is using unsafe, why bother?

> Here’s a post by the maintainer of hyper about what they accomplished in 2023 and what they hope to accomplish in 2024 - https://seanmonstar.com/blog/2023-in-review/

Ok, and that doesn't mention "unsafe" once - no justification for why it's used, much less a plan to reduce or eliminate it.

[flagged]