Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zlib-rs is faster than C

trifectatech.org

Post reply on HN
Print view View original

381–390 of 492 posts

Re: Zlib-rs is faster than C

#381

Post by pdimitar »

chjj wrote: post #380
pdimitar wrote: post #373

Earlier quoted context omitted.

Where do you see emotional reaction? All I do in each reply is point out how you generalize and get surprised that you are being called out. No emotional reactions. Show me where they are?

[flagged]

I am not upset with anything. That would imply I care what you think.

What I dislike, if we can even call it that, is that you misrepresent intentionally and are falling victim to extremely easy to avoid ego trips like claiming that your anecdotal evidence is universal.

That is not OK and is not intellectually fair.

Be intellectually fair. If you are not then I posit that you don't belong in tech as you have no scientific and analytic approach to things. That's my takeaway here.

You have left an extensive record of your bias in multiple comments. Including purposeful deflection and projection, as you try to make it out that I react emotionally. Which is false.

You seem like a lost cause though. So bye.

Re: Zlib-rs is faster than C

#382

Post by chjj »

pdimitar wrote: post #376
chjj wrote: post #371

Earlier quoted context omitted.

Fair enough. I suppose it is my most recent encounter. The result: I still don't like the rust community. You may have different opinions. I see no issue here.

I see the issue. Biased people like yourself don't belong in tech. For the record, I only picked Rust 5-ish years ago out of a 23 years of career. I know plenty of other languages. I was a skeptic at the start as well. Never generalized a pretty big group like you do though. You should be ashamed.

FTR I don't really have a problem with the rust language. I think there's some interesting ideas in there. I don't really like the syntax, but that's a minor nitpick.

Not sure what to make of your other comments.

Re: Zlib-rs is faster than C

#383

Post by cmrdporcupine »

anonymoushn wrote: post #227
cmrdporcupine wrote: post #99

Earlier quoted context omitted.

simd and allocator_api are the two that irritate me enough to consider a different language for future systems dev projects. I don't have the personality or time to wade into committee type work, so I have no idea what it would take to get those two across the finish line, but the allocator one in particular makes me question Rust for lower level applications. I think it's just not going to happen. If Zig had proper…

generic simd abstractions are of quite limited use. I'm not sure what's objectionable about the thing Rust has shipped (in nightly) for this, which is more or less the same as the stuff Zig has shipped for this (in a pre-1.0 compiler version).

The issue is that it's sitting in nightly for years. Many many many years.

I don't write software targetting nightly, for good reason.

Re: Zlib-rs is faster than C

#384

Post by steveklabnik »

datadeft wrote: post #360
steveklabnik wrote: post #64

Earlier quoted context omitted.

> unsafe {} when you need the absolute maximum performance available. Unsafe code is not inherently faster than safe code, though sometimes, it is. Unsafe is for when you want to do something that is legal, but the compiler cannot understand that it is legal.

True, however I only saw this happens to achieve max perf. I have very limited experience so this is confirmation bias from my end.

An example of unsafe not for performance is when interacting with hardware directly.

Re: Zlib-rs is faster than C

#385

Post by pdimitar »

chjj wrote: post #382
pdimitar wrote: post #376

Earlier quoted context omitted.

I see the issue. Biased people like yourself don't belong in tech. For the record, I only picked Rust 5-ish years ago out of a 23 years of career. I know plenty of other languages. I was a skeptic at the start as well. Never generalized a pretty big group like you do though. You should be ashamed.

FTR I don't really have a problem with the rust language. I think there's some interesting ideas in there. I don't really like the syntax, but that's a minor nitpick. Not sure what to make of your other comments.

And I didn't say this was about Rust the language. I said many times it's not OK for you to generalize an entire community of hard-working people. It will never be OK.

What is actually funny in our exchanges is that I don't even actively work with Rust anymore. I work with multiple languages, it included. I've met very smart, humble and fairly hardcore [Rust] devs from whom I learned a lot and got severely humbled as a result (as I was under the illusion that there's not much more I could learn in programming back then).

My other comments are fairly trivial English. Surely you can very easily make something out of them.

Re: Zlib-rs is faster than C

#386

Post by chjj »

pdimitar wrote: post #381
chjj wrote: post #380

Earlier quoted context omitted.

[flagged]

I am not upset with anything. That would imply I care what you think. What I dislike, if we can even call it that, is that you misrepresent intentionally and are falling victim to extremely easy to avoid ego trips like claiming that your anecdotal evidence is universal. That is not OK and is not intellectually fair. Be intellectually fair. If you are not then I posit that you don't belong in tech as you have no scien…

[flagged]

Re: Zlib-rs is faster than C

#387

Post by pdimitar »

chjj wrote: post #386
pdimitar wrote: post #381

Earlier quoted context omitted.

I am not upset with anything. That would imply I care what you think. What I dislike, if we can even call it that, is that you misrepresent intentionally and are falling victim to extremely easy to avoid ego trips like claiming that your anecdotal evidence is universal. That is not OK and is not intellectually fair. Be intellectually fair. If you are not then I posit that you don't belong in tech as you have no scien…

[flagged]

:)

Re: Zlib-rs is faster than C

#388

Post by tux3 »

vikramkr wrote: post #362
School-Cotton wrote: post #331

Earlier quoted context omitted.

No you don’t. You can use the standard linked list that is already included in the standard library. Coming up with these niche examples of things you need unsafe for in order to discredit rust’s safety guarantees is just not interesting. What fraction of programmer time is spent writing custom linked lists? Surely way less than 1%. In most of the other 99%, Rust is very helpful.

I think the point is that it's funny that the standard library has to use unsafe to implement a data structure that's like the second data structure you learn in an intro to CS class

No, that's how the feature is supposed to work.

You design an abstraction which is unsafe inside, and exposes a safe API to users. That is really how unsafe it meant to be used.

Of course the standard library uses unsafe. This is where you want unsafe to be, not in random user code. That's what it was made for.

Re: Zlib-rs is faster than C

#389

Post by chjj »

pdimitar wrote: post #385
chjj wrote: post #382

Earlier quoted context omitted.

FTR I don't really have a problem with the rust language. I think there's some interesting ideas in there. I don't really like the syntax, but that's a minor nitpick. Not sure what to make of your other comments.

And I didn't say this was about Rust the language. I said many times it's not OK for you to generalize an entire community of hard-working people. It will never be OK. What is actually funny in our exchanges is that I don't even actively work with Rust anymore. I work with multiple languages, it included. I've met very smart, humble and fairly hardcore [Rust] devs from whom I learned a lot and got severely humbled as…

My mistake. I thought your comment about being a skeptic was referring to the language itself.

It sounds like you had a good experience with the rust community. I'm glad it worked for you. But from what I've seen, it's not for me.

Re: Zlib-rs is faster than C

#390

Post by burntsushi »

DannyBee wrote: post #350
sunshowers wrote: post #123

Earlier quoted context omitted.

No, C lacks encapsulation of unsafe code. This is very important. Encapsulation is the only way to scale local reasoning into global correctness.

Hard disagree - if you violate the invariants in Rust unsafe code, you can cause global problems with local code. You can cause use-after-free, and other borrow checker violations, with incorrect unsafe code. Nothing will flag it, you will have no idea which unsafe code block is causing the isue, debugging will be hard. I have no idea what your definition of encapsulation is, but mine is not this. It's really only en…

The encapsulation referred to here is that you can expose a safe API that is impossible to misuse in a way that leads to undefined behavior. That's the succinct way of putting it anyway.

The `memchr` crate, for example, has an entirely safe API. Nobody needs to use `unsafe` to use any part of it. But its internals have `unsafe` littered everywhere. Could the crate have bugs that result in UB due to a particular use of the `memchr` API? Yes! Doesn't that violate encapsulation? No! A bug inside an encapsulated boundary does not violate the very idea of encapsulation itself.

Encapsulation is about blame. It means that if `memchr` exposes a safe API, and if you use `memchr` and you get UB as a result of some `unsafe` code inside of `memchr`, then that means the problem is inside of `memchr`. The problem is definitively not with the caller using the library. That is, they aren't "holding it wrong."

I'm surprised that someone with as much experience as you is missing this nuance. How many times have you run into a C library API that has UB, you report the bug and the maintainer says, "sorry bro, but you're holding that shit wrong, your fault." In Rust, the only way that ought (very specifically using ought and not is) to be true is if the API is tagged with `unsafe`.

Now, there are all sorts of caveats that don't change the overall point. "totally safe transmute" being an obvious demonstration of one of them[1] by fiddling with `/proc/self/mem`. And of course, Rust does have soundness bugs. But neither of these things change the fundamental idea of encapsulation.

And yes, one obvious shortcoming of this approach is that... well... people don't have to follow it! People can lie! I can expose a safe API, you can get UB and I can reject blame and say, "well you're holding it wrong." And thus, we're mostly back into how languages like C deal with these sorts of things. And that is indeed a bummer. And there are for sure examples of that in the ecosystem. But the glaring thing you've left out of your analysis is all of the crates that don't lie and specifically set out to provide a sound API.

The great thing about progress is that we don't have to perfect. I'm really disappointed that you seem to be missing the forest for the trees here.

[1]: https://github.com/ben0x539/totally-safe-transmute/blob/main...

Post reply on HN