Speed of Rust vs. C • Hacker News Board

Re: Speed of Rust vs. C

#481

Post by BatmanAoD » Sun, Mar 14, 2021, 4:05 AM UTC

up2isomorphism wrote: post #283

My experience is that languages survives not because of a particular feature, but because they are USEFUL in practice to produce a software. The fact that C is used in so many places speaks for itself about it usefulness. And this is done by writing software by majority of C programmers instead of jumping on every forum to attack other languages, writing extended blog posts just to convince people that they "should"…

Nothing in this article seems to be saying that C "isn't useful". It also doesn't state that bounds checks are the "most difficult thing in software development."

As the article mentions, C is 50 years old. The fact that it's still used is evidence of its usefulness, sure. It has outlasted almost all of its peers.

Rust has been stable for under 6 years. In that time, it's been adopted by a slew of major companies, and people have used their free time to write some extremely good software in it. So by that metric, Rust's usefulness speaks for itself, too.

Re: Speed of Rust vs. C

#482

Post by jblow » Sun, Mar 14, 2021, 4:39 AM UTC

steveklabnik wrote: post #479

jblow wrote: post #458

Earlier quoted context omitted.

> rather than sweeping, incorrect statements that lead people to believe things that aren't true I agree, and if I say things that are incorrect, then I definitely want to fix them, because I value being correct. But what I am meeting in this thread is people wanting to do some language-lawyer version of trying to prove I am incorrect, without addressing the substance of what I am actually saying. I think your replie…

> So if something I am saying doesn't seem to make sense, or seems "incorrect", well, maybe it's that I am just coming from a very different place in terms of what good programming looks like. I do think this is probably true, and I know you do care about this! The thing is... > The code that I write just looks way different from the code you guys write, the things I think about are way different, etc. This is also p…

> they ensure that the pointers don't last longer than the arena lives. That's it.

Sure, but my point is, when most things have lifetimes tied to the same arena, this becomes a almost a no-op. Both in the sense of, you are not really checking much (as Ayn Rand said, 'a is 'a), and you're paying a lot in terms of typing stuff into the program, and waiting around for the compiler to be not usefully checking all these things that are the same. Refactoring a program so that most things' lifetimes are the same does not feel to me like it's in the spirit of Rust, because then why have all these complicated systems, but maybe you feel that it is.

There is a bit of a different story when you are heavily using threads, because you want those threads to have allocators that are totally decoupled from each other (because otherwise waiting on the allocator becomes a huge source of inefficiency). So then there are more lifetimes. But here I am not convinced about the Rust story either, because here too I think there are simpler things to do that give you 95% of the benefit and are much lower-friction.

Re: Speed of Rust vs. C

#483

Post by Blikkentrekker » Sun, Mar 14, 2021, 4:42 AM UTC

pornel wrote: post #377

Blikkentrekker wrote: post #77

Earlier quoted context omitted.

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.

OpenSSL, like many other software indeed used a custom allocator, but this hasn't much to do with this to anything at all, as the system allocator also strongly favors giving back memory that once belonged to the same process, as it has to zero memory that belonged to other processes first.

This is of course a kernel feature when the lower level primitives are used that ask for blocks of memory from the kernel, which zeroes them if they had belonged to another process prior, and does not when they had not, and thus strongly favors giving back own memory. — allocators, such as the standard library's one or any custom ones, are built on top of these primitives.

Re: Speed of Rust vs. C

#484

Post by jblow » Sun, Mar 14, 2021, 5:02 AM UTC

jblow wrote: post #482

steveklabnik wrote: post #479

Earlier quoted context omitted.

> So if something I am saying doesn't seem to make sense, or seems "incorrect", well, maybe it's that I am just coming from a very different place in terms of what good programming looks like. I do think this is probably true, and I know you do care about this! The thing is... > The code that I write just looks way different from the code you guys write, the things I think about are way different, etc. This is also p…

> they ensure that the pointers don't last longer than the arena lives. That's it. Sure, but my point is, when most things have lifetimes tied to the same arena, this becomes a almost a no-op. Both in the sense of, you are not really checking much (as Ayn Rand said, 'a is 'a), and you're paying a lot in terms of typing stuff into the program, and waiting around for the compiler to be not usefully checking all these t…

(And I will admit here that "Rust doesn't allow you to X", as I said originally, is not an accurate statement objectively. Attempting to rephrase that objection to be better, I would say, by the time you are doing all this stuff, you are outside the gamut that Rust was designed for, so by doing that program in Rust you are taking a lot of friction, but not getting the benefit given to someone who stays inside that gamut, so, it seems like a bad idea.)

Re: Speed of Rust vs. C

#485

Post by kbenson » Sun, Mar 14, 2021, 5:18 AM UTC

fhunt wrote: post #475

Animats wrote: post #390

Earlier quoted context omitted.

Since this got so many upvotes, I'll say a bit more. I'm writing a viewer for a virtual world. Think of this as a general-purpose MMO game client. It has no built-in game assets. Those are downloaded as needed. It's a big world, so as you move through the world, more assets are constantly being downloaded and faraway objects are being removed. The existing viewers are mostly single thread, in C++, and they run out of…

My question is probably off because I lack the knowledge but how do the commercial games/game engines do this then if this is such a rocket science? Something like Fortnite or an aged GTA do what you've described (downloading assets on demand without any fps-drop) for quite some time now.

The claim isn't that it's impossible, or "rocket science", it's that it's hard to do right and was made much easier. You're bringing up for comparison a game engine that has been in constant development by experts for over two decades (Unreal Engine) and a game engine in constant development for over a decade ago (RAGE). Just because someone makes a professional product using tens or hundreds of millions of dollars doesn't mean it was easy.

There's a reason why Epic is able to charge a percentage of sales for their engine, and companies still opt for it. That's because it's hard to do reliably and with good performance and visuals.

Re: Speed of Rust vs. C

#486

Post by Rusky » Sun, Mar 14, 2021, 5:30 AM UTC

jblow wrote: post #453

Rusky wrote: post #443

Earlier quoted context omitted.

> Okay, but if I do this everywhere, then I de facto don't have memory safety. No, that's not how this works. You write the unsafe code in one place and make sure it's correct (just like you'd do in C or Jai), and then you wrap it in a function signature that lets the compiler apply its memory safety checks to all the places that call it (this is what Rust gives you over C). This is still a meaningful improvement to…

> that lets the compiler apply its memory safety checks to all the places that call it My point is that those memory safety checks are now meaningless. > This is still a meaningful improvement to memory safety over C. No, it really isn't. What you are describing is almost exactly what you get in C.

They're conditionally meaningful: if a small amount of your program is correct, the entire program satisfies some useful properties.

This may or may not be something you care about, but it is certainly a meaningful tool that is quite useful to me, including when I use your type (3) style described in the sibling thread.

Re: Speed of Rust vs. C

#487

Post by Rusky » Sun, Mar 14, 2021, 5:52 AM UTC

jblow wrote: post #484

jblow wrote: post #482

Earlier quoted context omitted.

> they ensure that the pointers don't last longer than the arena lives. That's it. Sure, but my point is, when most things have lifetimes tied to the same arena, this becomes a almost a no-op. Both in the sense of, you are not really checking much (as Ayn Rand said, 'a is 'a), and you're paying a lot in terms of typing stuff into the program, and waiting around for the compiler to be not usefully checking all these t…

(And I will admit here that "Rust doesn't allow you to X", as I said originally, is not an accurate statement objectively. Attempting to rephrase that objection to be better, I would say, by the time you are doing all this stuff, you are outside the gamut that Rust was designed for, so by doing that program in Rust you are taking a lot of friction, but not getting the benefit given to someone who stays inside that ga…

> Refactoring a program so that most things' lifetimes are the same does not feel to me like it's in the spirit of Rust, because then why have all these complicated systems, but maybe you feel that it is.

I think a common sentiment among Rust programmers would instead phrase this as, "the complicated system we designed to find bugs keeps yelling at us when we have lots of crazy lifetimes flying around, so presumably designs that avoid them might be better."

In this sense, even for someone who doesn't feel the borrow checker is worth it in their compiler, this can just be taken as a general justification for designs in any language that have simpler lifetime patterns. If they're easier to prove correct with static analysis, maybe they're easier to keep correct by hand.

Re: Speed of Rust vs. C

#488

Post by eru » Sun, Mar 14, 2021, 6:15 AM UTC

rbanffy wrote: post #448

eru wrote: post #177

Earlier quoted context omitted.

> [...] or is encapsulated, out of sight, out of reach of meddling hands. That's the real issue here! Most language have poor abstractions for parallelism and concurrency. (Many languages don't even differentiate between the two.) Encapsulating and abstracting is how we make things usable. Eg letting people roll hash tables by themselves every time they want to use one, would lead to people shooting themselves in the…

> Exactly because they move all the fiddly bits out of the reach of meddling hands. You don't even need to hide those out of reach. You just need to make it dead simple to use and pretty much nobody will want to touch the fiddly bits. And those who do know they had it coming.

Oh, definitely. You just need to make it so that people don't have to fiddle with it and don't fiddle with it by accident.

You seldom have to protect against malicious attempts. (But when you do, it's a much harder task.)

Re: Speed of Rust vs. C

#489

Post by eru » Sun, Mar 14, 2021, 6:15 AM UTC

pjmlp wrote: post #329

eru wrote: post #175

Earlier quoted context omitted.

> Some people even feel C++ keeps adding too many new features too fast. It's not so much that they keep adding features, but that they (almost?) never remove any.

Python 3 has shown the world what happens when that is done without bringing the ecosystem along.

Haskell has also removed some features over time.

Re: Speed of Rust vs. C

#490

Post by eru » Sun, Mar 14, 2021, 6:16 AM UTC

anaerobicover wrote: post #363

eru wrote: post #175

Earlier quoted context omitted.

> Some people even feel C++ keeps adding too many new features too fast. It's not so much that they keep adding features, but that they (almost?) never remove any.

Are there many other programming languages that remove features?

Python 3 made some backwards incompatible changes. Haskell removed some features over time, as well.