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

Speed of Rust vs. C

kornel.ski

Post reply on HN
Print view View original

371–380 of 546 posts

Re: Speed of Rust vs. C

#371

Post by howinteresting »

hctaw wrote: post #362
howinteresting wrote: post #325

Earlier quoted context omitted.

Bothsidesism is unhelpful in technical discussions just as much as in politics. If you have specific critiques please share them. I have a number of specific critiques of Rust, chief being that APIs and implementations are bound too tightly. &[String] and &[&str] are logically similar but changing from one to the other in your implementation might mean a breaking API change.

fn func (slice: &[impl AsRef ]) { // ... }

* You have to remember to do that.

* I was thinking return values.

* Also you can't use that style in an enum definition if you want to return a custom enum.

Re: Speed of Rust vs. C

#372

Post by steveklabnik »

cambalache wrote: post #358
nindalf wrote: post #264

Earlier quoted context omitted.

The problem is that most people criticising Rust don't make the case very well. If you want to read good critique, I'd recommend this - https://matklad.github.io/2020/09/20/why-not-rust.html . This post up-to-date, succinct and objective. And most pertinently, this critique was written by someone who genuinely loves programming in Rust. Shows you that Rust users aren't blinded to the faults of the language. You shoul…

> And most pertinently, this critique was written by someone who genuinely loves programming in Rust. That is putting the bar impossible high. I would expect most of the criticism to come from people who hate to program in Rust, which it is fine as long as the criticism is well argued.

You've got the contrapositive there. The claim was that folks who love Rust do not accept criticism of the language. Therefore, a criticism by someone who loves the language was presented, to show that claim was false. Your parent isn't saying that only folks who love Rust can criticize Rust.

Re: Speed of Rust vs. C

#373

Post by steveklabnik »

jblow wrote: post #335
zozbot234 wrote: post #331

Earlier quoted context omitted.

> (If you don't get what I am saying here, it might help to know that performance programmers consider malloc to be tremendously slow and don't use it except at startup or in cases when it is amortized by a factor of 1000 or more). Rust is now getting support for custom local allocators ala C++, including in default core types like Box , Vec and HashMap . It's an unstable feature, hence not yet part of stable Rust bu…

Sure, but you are still going to be constrained greatly in terms of what those allocators are able to do, are you not?

In what way? What kind of constraints are you imagining here?

Re: Speed of Rust vs. C

#374

Post by steveklabnik »

Tuna-Fish wrote: post #368
steveklabnik wrote: post #365

Earlier quoted context omitted.

This is not a trait object, and so that part of the reference is irrelevant. Here's that example working: https://play.rust-lang.org/?version=stable&mode=debug&editio... I am not entirely sure that it answers your point though; what you want is trait A or trait B, not both, right?

Ah sorry, no, what I want is specifically a trait object that satisfies both trait A and B.

Yes, in that case you are 100% right, your parent didn't provide an actual solution.

Re: Speed of Rust vs. C

#375

Post by planetis »

nindalf wrote: post #264
planetis wrote: post #176

Its just amusing, in this thread everyone with critical thinking and skeptical is down voted, even if one expresses himself moderately. It shows how much of zealots, Rust fanboys have become.

The problem is that most people criticising Rust don't make the case very well. If you want to read good critique, I'd recommend this - https://matklad.github.io/2020/09/20/why-not-rust.html . This post up-to-date, succinct and objective. And most pertinently, this critique was written by someone who genuinely loves programming in Rust. Shows you that Rust users aren't blinded to the faults of the language. You shoul…

> You shouldn't think that Rust users are fanboys just because you see push back to low effort, low knowledge critiques.

That's too much assuming, btw I read in this thread a comment from a well-known Nim dev working in multithreading (with much knowledge on the subject) and it was downvoted to oblivion.

Re: Speed of Rust vs. C

#376

Post by up2isomorphism »

steveklabnik wrote: post #312
up2isomorphism wrote: post #299

Earlier quoted context omitted.

There is simply no way you can enforce "thread safety on ALL data", unless you pay unreasonable amount of synchronization costs, which in that case, is a trivial thing to accomplish. This is as same as some one tell you that you will never loose any money by investing a certain asset.

How well do you know Rust, and how it works, and what it guarantees? Like, do you have a specific objection to the way Rust accomplishes this?

"thread safety for all data" is not even a well-defined term, I do not know what you are trying to argue about.

Re: Speed of Rust vs. C

#377

Post by pornel »

Blikkentrekker wrote: post #77
viraptor wrote: post #6

Earlier quoted context omitted.

It's not trivial to write a funny and clever burn, but this just hits the spot...

It's incorrect, however. Heartbleed wasn't caused by reusing buffers; it was caused by not properly sanitizing the length of the buffer from entrusted input, and reading over it's allocated size, thus allowing the attacker to read into memory that wasn't meant for him.

OpenSSL had its own memory-recycling allocator, which made the bug guarantee leaking OpenSSL's own data. Of course leaking random process memory wouldn't be safe either, but the custom allocator added that extra touch.

Re: Speed of Rust vs. C

#378

Post by [deleted] »

up2isomorphism wrote: post #376
steveklabnik wrote: post #312

Earlier quoted context omitted.

How well do you know Rust, and how it works, and what it guarantees? Like, do you have a specific objection to the way Rust accomplishes this?

"thread safety for all data" is not even a well-defined term, I do not know what you are trying to argue about.

[deleted]

Re: Speed of Rust vs. C

#379

Post by mratsim »

ben0x539 wrote: post #161
mratsim wrote: post #150

> There are other kinds of concurrency bugs, such as poor use of locking primitives causing higher-level logical race conditions or deadlocks, and Rust can't eliminate them, but they're usually easier to diagnose and fix. Which is why so many people are creating formal verification languages and spending years in research to fix those ... That just isn't true. It's a very complex problem that is an issue in both hard…

Rust may or may not help you write synchronization primitives safely, but it for sure helps you use synchronization primitives without having to worry about memory safety. If you aren't parallelizing particularly subtle shenanigans, that's plenty for fearlessness.

Coming up with a new threadsafe queue design is worthy of a paper even though it's just enqueueing and dequeueing items.

Memory safety is just a small part and is a much easier problem than ensuring the absence of race conditions.

Re: Speed of Rust vs. C

#380

Post by rocqua »

cb321 wrote: post #211
rocqua wrote: post #191

Earlier quoted context omitted.

They are either based on void * with performance issues, or macro based with weird ergonomics that look like function calls, but aren't. It's doable, but not very easy.

You are right in a library-demographical sense, but not in a fundamental sense. There is a 3rd way. Have a look at the CTL I linked to (downvoted..maybe I should have explained more?). Once you give up the closed source/prebuilt binary library idea and embrace the C++-like header library idea and write implemenations in terms of "assumed macro/inline function" definitions, the problem becomes straightforward with no…

I had a look, and it feels like template programming but with even worse guarantees.

Having a type declaration dependent on #define P whether it is plain old data or not, and needing to know what that means, is not the kind of ergonomics I'd want. That requires learning a whole new paradigm to ensure I am not doing wrong things.

In my mind it is so big an extension of the C language, that it leaves the C headspace and becomes its own headspace.

Post reply on HN