Live data from Hacker News

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

bitbashing.io

21–30 of 47 posts

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

#21
post #18
post #16

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…

[flagged]

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

#22
post #20
post #17

Earlier 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]

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

#23
post #12
post #6

Earlier 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…

FWIW, either async-channel's types or flume's async APIs should work for your use case. Both are completely agnostic to the async runtime, since the futures are triggered by internal events (recv() waits for send() and vice versa), rather than external events like I/O which are generally coordinated through the runtime.

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

#24
post #22
post #20

Earlier 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.

[flagged]

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

#25
post #20
post #17

Earlier 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]

> It contributed nothing worthwhile, but I’m happy it got you your 15 minutes on HN.

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

#26
post #11

I 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…

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.

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

#27

Earlier 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.

That's my main goal - and Rust seems like the language where we can have our cake and eat it too! The standard library has some amazingly performant data structures and algorithms.

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
post #8

> 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…

> Seriously, it should not be hard to efficiently strip a prefix off a u8 slice in safe Rust. For example, split_first.

That is a good idea for a contribution, no?

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

#29
post #21
post #18

Earlier 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]

[flagged]

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

#30

It 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.

I think the competition can drive the standard to improve.

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.

Post reply on HN