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 exist…
> 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 lik…
Unsafe at Any Speed: Tradeoffs and Values in the Rust Ecosystem
21–30 of 47 posts
Re: Unsafe at Any Speed: Tradeoffs and Values in the Rust Ecosystem
#22Earlier quoted context omitted.
The article got me in touch with one of the hyper devs, and we had a very friendly conversation that taught me a lot. If questioning some design decisions and calling a marketing blurb a little disingenuous is mocking and condescending, they didn't seem to think so.
[flagged]
If the reason I blogged about my coding hobby was to "get my 15 minutes on HN", I would be a deeply unhappy person.
Re: Unsafe at Any Speed: Tradeoffs and Values in the Rust Ecosystem
#23Earlier quoted context omitted.
> by the fact that async isn't in the standard library I wish async/await were not in the language
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 looki…
Re: Unsafe at Any Speed: Tradeoffs and Values in the Rust Ecosystem
#24Earlier quoted context omitted.
[flagged]
Turns out we regularly play flight sims together on weekends, but didn't know about each others' software misadventures - small world, isn't it? If the reason I blogged about my coding hobby was to "get my 15 minutes on HN", I would be a deeply unhappy person.
Re: Unsafe at Any Speed: Tradeoffs and Values in the Rust Ecosystem
#25Earlier quoted context omitted.
The article got me in touch with one of the hyper devs, and we had a very friendly conversation that taught me a lot. If questioning some design decisions and calling a marketing blurb a little disingenuous is mocking and condescending, they didn't seem to think so.
[flagged]
That is a very rude dismissal, followed by a bad faith implication of the author's motivations. You can do better.
I got something worthwhile out of it. I'm learning Rust and, like the author of the blog post, tend to value safety (simplicity hopefully being a contributor to that) over that last bit of performance. I was actually looking over the source of some of the libraries I'm considering using, am concerned about some things I found, didn't know about ureq, now I do, and I think it's going to fit my needs.
Thanks, mrkline!
Re: Unsafe at Any Speed: Tradeoffs and Values in the Rust Ecosystem
#26I want to make a sign on the wall that denotes $x days since someone complained about Tokio + Reqwest being bloated and/or making their own design decisions. I also want to make a campaign to direct people to ureq first so we stop hearing about this every other month. Reqwest is very good and worth just using IMO, but if you really care about this, ureq is pretty battle tested and a fine option for "just give me a fu…
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…
> the author just wants a simple HTTP client for Rust that prioritizes simplicity over raw performance
I saw it as:
> the author just wants a safe HTTP client for Rust that prioritizes safety over raw performance
That resonates with me as well.
Re: Unsafe at Any Speed: Tradeoffs and Values in the Rust Ecosystem
#27Earlier quoted context omitted.
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…
I read it slightly differently. > the author just wants a simple HTTP client for Rust that prioritizes simplicity over raw performance I saw it as: > the author just wants a safe HTTP client for Rust that prioritizes safety over raw performance That resonates with me as well.
Talking to one of the hyper developers, a lot of this machinery was made before it arrived in the stdlib. My response was, "neat, so we can delete the custom stuff now, right? :P" but I suppose any change carries some risk with it.
Re: Unsafe at Any Speed: Tradeoffs and Values in the Rust Ecosystem
#28> or even just skipping blank lines, hyper does things its own way. Ugh. IMO a bit benefit of Rust is that you can’t do wild-west-YOLO buffer twiddling without “unsafe,” so people will write better code. But it really looks like httparse missed the memo. https://github.com/seanmonstar/httparse/blob/v1.8.0/src/iter... iter::Bytes looks like an awkward wrapper around slices with all the safety removed. So you can port…
That is a good idea for a contribution, no?
Re: Unsafe at Any Speed: Tradeoffs and Values in the Rust Ecosystem
#29Earlier quoted context omitted.
> 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 lik…
[flagged]
Re: Unsafe at Any Speed: Tradeoffs and Values in the Rust Ecosystem
#30It is great when there is a standard that works well for everyone. It is great when there is competition to that bloated monopoly everyone currently uses. I don't understand my own cognitive dissonance on this topic.
People can see improvements in alternatives that still align with their principals and adopt them.
So in that regard, I don't think they are disjunct ideas.