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

Being fair about memory safety and performance

thecodedmessage.com

Post reply on HN
Print view View original

51–60 of 75 posts

Re: Being fair about memory safety and performance

#51

Post by pcwalton »

_vvhw wrote: post #20
saagarjha wrote: post #16

This article has a core point which is good: “in Rust the default is safe, and you have to opt-in to unsafety, but in C++ the default is unsafe, and you have to opt-in to safety”. I think it’s easy to argue for Rust using this construction, because, well, that’s the entire point why Rust was created. But, it really doesn’t take a very long post to talk about this. The remainder goes off the rails, talking about “C++…

> This article has a core point which is good: “in Rust the default is safe, and you have to opt-in to unsafety, but in C++ the default is unsafe, and you have to opt-in to safety”. On the subject of safe defaults, just to correct that Rust does not in fact have as much default memory safety with regards to buffer bleeds (e.g. variants of OpenSSL's Heartbleed) as it could [1], because it has unchecked arithmetic (int…

Do you have examples of this actually causing security problems in Rust code at anywhere near the levels of memory safety problems in C/C++?

It strikes me as extremely dubious to tout Zig, which doesn't have memory safety at all, as somehow superior to Rust because Zig has this mitigation enabled by default (with a large performance cost) for an error class that Rust forestalls the vast majority of the negative consequences of, by dint of memory safety.

Re: Being fair about memory safety and performance

#52

Post by pcwalton »

alexhutcheson wrote: post #46
pron wrote: post #12

I'm not quite sure who this article is aimed at, and who those "C++ apologists" are, but as someone who programs in C++ all day, doesn't like it at all, and yet won't advocate to switch to Rust, these kinds of arguments are unconvincing. I'm not advocating to switch to Rust not because I don't think it's better than C++. I am absolutely, 100% convinced that Rust is technically better than C++ in most possible ways —…

> Rust is technically better than C++ in most possible ways — in some, significantly better — and worse in almost no way. It's much worse in one way: Interoperation with existing C++ code. Sure, that's not a fair criteria - C++ is designed in a way that makes it almost impossible for other languages to use C++ libraries without a heavyweight wrapper like SWIG. However, even though it's not fair , it's still really im…

Have you tried cxx? C++ interoperability in Rust has come a long way.

Re: Being fair about memory safety and performance

#53

Post by pcwalton »

pron wrote: post #40
eklavya wrote: post #33

Earlier quoted context omitted.

Every large project with years of code (legacy or well maintained) will be hardly ever re-written with complete success. It's not a property of programming language in my opinion. It's just economic sense. I doubt JDK will be rewritten in Rust/Zig, they did GraalVM in Java though. Zig might be revolutionary but personally for me Rust is why I can dare write non gc code. I never thought I would ever be robotically pre…

Even if you look just at sound language guarantees, Zig is closer to Rust in terms of memory safety than to C or C++. That it doesn't make all of Rust's static guarantees doesn't put it in the same bucket as languages that make none. Once you reduce memory safety issues to below half of their current rate, there are different paths to achieving a good overall correctness story.

Zig is no way closer to Rust than C or C++ in this regard. Zig is in fact not appreciably safer than C or C++. All of the same classes of memory safety problems that are present in C or C++ are present in Zig.

I am extremely doubtful of the claim that Zig eliminates 50% or more of memory safety problems.

Re: Being fair about memory safety and performance

#54

Post by errantmind »

fulafel wrote: post #22
celeritascelery wrote: post #15

Earlier quoted context omitted.

> predicted, not-taken branches tend to have 0 cycle latency in recent CPUs. This is not the case. Due to instruction level parallelism, the throughput could be unaffected, but you will always have latency penalty. The CPU still needs to run the check (access the length and compare it to the index) and this adds latency. On top of that, it also increases code size, which can impact the instruction cache and binary si…

Speculative execution enables continuing along the predicted branch without stopping. You do need to have the ~2 instructions to get the length test input on hand but that usually can be eaten by insn level parallelism without hurting the latency of the array operation.

Do you have any evidence of this claim? Perhaps a benchmark?

This doesn't align with any of my performance optimization experience.

Re: Being fair about memory safety and performance

#55

Post by alexhutcheson »

pcwalton wrote: post #52
alexhutcheson wrote: post #46

Earlier quoted context omitted.

> Rust is technically better than C++ in most possible ways — in some, significantly better — and worse in almost no way. It's much worse in one way: Interoperation with existing C++ code. Sure, that's not a fair criteria - C++ is designed in a way that makes it almost impossible for other languages to use C++ libraries without a heavyweight wrapper like SWIG. However, even though it's not fair , it's still really im…

Have you tried cxx? C++ interoperability in Rust has come a long way.

cxx is a huge improvement over manually writing bindings in C (with the inherent limitations imposed by C’s lack of expressiveness). At the same time, you still have to write a cxx::bridge to specify every boundary between Rust and C++ code, and the clients of on either side need to code against some generated code, not a simple .rs or .h file. It’s a huge improvement, but it’s still a lot more developer effort and boilerplate to use a C++ class from a Rust file than it would be to use that same C++ class from another C++ file.

cxx also can only handle a subset of the interfaces expressive in C++. If you haven’t written the interface with the specific goal of making it usable via cxx, it’s pretty likely you’ll have issues wrapping it with cxx.

Re: Being fair about memory safety and performance

#56

Post by dralley »

pcwalton wrote: post #53
pron wrote: post #40

Earlier quoted context omitted.

Even if you look just at sound language guarantees, Zig is closer to Rust in terms of memory safety than to C or C++. That it doesn't make all of Rust's static guarantees doesn't put it in the same bucket as languages that make none. Once you reduce memory safety issues to below half of their current rate, there are different paths to achieving a good overall correctness story.

Zig is no way closer to Rust than C or C++ in this regard. Zig is in fact not appreciably safer than C or C++. All of the same classes of memory safety problems that are present in C or C++ are present in Zig. I am extremely doubtful of the claim that Zig eliminates 50% or more of memory safety problems.

The language by itself, perhaps not, I don't know.

But, the fact that it has a test framework built in, and the test allocator fails when it detects memory problems (like a built-in valgrind) definitely puts it far above C in terms of making it easy to write correct code.

Re: Being fair about memory safety and performance

#57

Post by pcwalton »

dralley wrote: post #56
pcwalton wrote: post #53

Earlier quoted context omitted.

Zig is no way closer to Rust than C or C++ in this regard. Zig is in fact not appreciably safer than C or C++. All of the same classes of memory safety problems that are present in C or C++ are present in Zig. I am extremely doubtful of the claim that Zig eliminates 50% or more of memory safety problems.

The language by itself, perhaps not, I don't know. But, the fact that it has a test framework built in, and the test allocator fails when it detects memory problems (like a built-in valgrind) definitely puts it far above C in terms of making it easy to write correct code.

When I say that a language isn't meaningfully better than C in terms of memory safety, I mean C as programmed in 2022, which very much includes ASan.

Re: Being fair about memory safety and performance

#58

Post by AnimalMuppet »

flykespice wrote: post #29
pron wrote: post #12

I'm not quite sure who this article is aimed at, and who those "C++ apologists" are, but as someone who programs in C++ all day, doesn't like it at all, and yet won't advocate to switch to Rust, these kinds of arguments are unconvincing. I'm not advocating to switch to Rust not because I don't think it's better than C++. I am absolutely, 100% convinced that Rust is technically better than C++ in most possible ways —…

Expecting a language be better "enough" is an unrealistic one, you will be waiting forever. Of course no language will be perfect to a specific domain, there is no objective metric every individual has their own needs and no universal language can cater all them at once, there will be trade offs. Rust is already better enough( and possibly will take decades before another language "suceeds" it), choose it or be on th…

> Expecting a language be better "enough" is an unrealistic one, you will be waiting forever.

Disagree. I think the "market" (the set of programmers) defines "enough". When a language is enough better (in some area, doesn't have to be all areas) you see widespread adoption.

C was enough better than PL/I, ALGOL, and assembly. Java was enough better than C++. (Why? Garbage collection, and the huge standard library.)

So far, Rust is not enough better than C++.

Now, I know this is kind of circular. I'm saying that a language is "enough" better if it wins in the market, and I'm saying that a language wins in the market if it's enough better. But I have some trust in programmers, that they are not just sheep. If a language is better than other languages in a way that matters to actual working programmers, a fair number of them will use it.

Re: Being fair about memory safety and performance

#59

Post by adgjlsfhk1 »

robalni wrote: post #37
__s wrote: post #34

Earlier quoted context omitted.

https://en.wikipedia.org/wiki/Memory_safety Outside of your simple example C code, there exists C code which can only be memory safe if the compiler implements a heavy runtime: track pointer allocations, track where pointers source from, raise an error when the pointer is used in an undefined context. See how much work valgrind does to achieve a subset of this task You could consider C code safe if you included a mac…

That wiki article seems to define memory-safe code as not containing an arbitrary list of bugs. This doesn't really make sense because even if you have code that doesn't contain those bugs, and even if you have a compiler that helps you to find those bugs, programming is always unsafe. You are not safe just because you don't use the "unsafe" keyword in Rust.

The list isn't arbitrary. Bugs that let you read and write different memory than you meant to are some of the easiest to exploit. If you look back at the type of bugs that make headlines, they're pretty much all memory safety issues or code injection (and the memory issues show up more often).

Re: Being fair about memory safety and performance

#60

Post by jbergens »

AnimalMuppet wrote: post #58
flykespice wrote: post #29

Earlier quoted context omitted.

Expecting a language be better "enough" is an unrealistic one, you will be waiting forever. Of course no language will be perfect to a specific domain, there is no objective metric every individual has their own needs and no universal language can cater all them at once, there will be trade offs. Rust is already better enough( and possibly will take decades before another language "suceeds" it), choose it or be on th…

> Expecting a language be better "enough" is an unrealistic one, you will be waiting forever. Disagree. I think the "market" (the set of programmers) defines "enough". When a language is enough better (in some area, doesn't have to be all areas) you see widespread adoption. C was enough better than PL/I, ALGOL, and assembly. Java was enough better than C++. (Why? Garbage collection, and the huge standard library.) So…

I neither a c++ programmer nor a rust one but I read things about programming. My take is that rust is near the breaking point where it becomes so commonly used that more teams and organizations will just start to use it.

The risk of switching for at least parts or a code base will seem low and then it probably looks better enough.

Of course some organizations and code bases are harder to change for some reason or reasons but many will probably start the conversion in the next 5 years. Unless rust just stops growing or something truly better comes along. I personally don't expect something much better soon and I think rust will continue to grow in usage.

Post reply on HN