Earlier quoted context omitted.
[flagged]
[flagged]
You have no idea what you’re talking about. You’re so confidently incorrect about Rust that there’s no point even trying to educate you. Good day.
Unsafe at Any Speed: Tradeoffs and Values in the Rust Ecosystem
31–40 of 47 posts
Re: Unsafe at Any Speed: Tradeoffs and Values in the Rust Ecosystem
#32Earlier quoted context omitted.
[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 loo…
I got a lot out of it too.
I have been using Rust, casually, for about eight years.
Sometimes in Rust it is hard to find simple things that solve simple problems.
Re: Unsafe at Any Speed: Tradeoffs and Values in the Rust Ecosystem
#33Earlier 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…
> So just ignore the async use cases? Or force tokio or similar to support it?
Hell no!
Do it differently
Re: Unsafe at Any Speed: Tradeoffs and Values in the Rust Ecosystem
#34Earlier quoted context omitted.
[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 loo…
[flagged]
Re: Unsafe at Any Speed: Tradeoffs and Values in the Rust Ecosystem
#35Earlier quoted context omitted.
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…
> So just ignore the async use cases? Or force tokio or similar to support it? Hell no! Do it differently
Differently how?
And perhaps more importantly, what tradeoff(s) would those differences entail?
Re: Unsafe at Any Speed: Tradeoffs and Values in the Rust Ecosystem
#36> 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?
You mean like this one?
https://github.com/seanmonstar/httparse/pull/86/files#diff-4...
Re: Unsafe at Any Speed: Tradeoffs and Values in the Rust Ecosystem
#37There’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…
> The key benefit of Rust is supposed to be better memory safety than C; if everything is using unsafe, why bother?
Is Hyper all contained inside unsafe block? As far as I know it is not. So even if there is some unsafe code it is not same as writing it in C.
Re: Unsafe at Any Speed: Tradeoffs and Values in the Rust Ecosystem
#38Earlier quoted context omitted.
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…
> So just ignore the async use cases? Or force tokio or similar to support it? Hell no! Do it differently
[deleted]
Re: Unsafe at Any Speed: Tradeoffs and Values in the Rust Ecosystem
#39Earlier quoted context omitted.
> So just ignore the async use cases? Or force tokio or similar to support it? Hell no! Do it differently
Differently how? And perhaps more importantly, what tradeoff(s) would those differences entail?
Green threads/Virtual threads are one solution, but then you need to ship a runtime for them, then you pay for what you don't use.
Or don't standardize on them and have a split ecosystem of half libs supporting use `green-thread.rs` and the other half supporting `rust-gthreads`.
Re: Unsafe at Any Speed: Tradeoffs and Values in the Rust Ecosystem
#40Earlier quoted context omitted.
> 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?
You mean like this one? https://github.com/seanmonstar/httparse/pull/86/files#diff-4...
Follow up -- the benchmarks on that PR look poor, but the benchmarks don't actually quite measure what they're expected to measure -- they're not black-boxing inputs, so the compiler has an opportunity to constant-fold in some cases.
I raised a PR to fix the benchmarks: https://github.com/seanmonstar/httparse/pull/151