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

Safety: A comparaison between Rust, C++ and Go

nested.substack.com

Post reply on HN
Print view View original

131–140 of 188 posts

Re: Safety: A comparaison between Rust, C++ and Go

#131

Post by jjnoakes »

jjnoakes wrote: post #83
benreesman wrote: post #66

Earlier quoted context omitted.

The sibling says that C++ has the wrong defaults, full stop. Well in Rust the default `HashMap` uses a cryptographic hash, and you see it everywhere , it's the de facto community "default". In C++ the community "default" is `absl::flat_hash_map`/`folly::F14`, which use SIMD to compare a whole stripe of key-prefixes simultaneously. I want different defaults for different programs, but the idea that it's esoteric to ev…

Why do you think that a language with better details would prevent you from opting in to whatever non-default behavior you need? Having the "right" defaults is better for everyone. Folks who don't know or care get a good, safe default with no undefined behavior or unexpected danger, and folks who know better can opt into something that fits their needs explicitly. Seems ideal to me.

> a language with better details

Whoops - that should have said "a language with better defaults"...

Re: Safety: A comparaison between Rust, C++ and Go

#132

Post by ncmncm »

benreesman wrote: post #66
tialaramex wrote: post #48

Earlier quoted context omitted.

> They are remarkably similar, just with different defaults. I'm going to lead with this, because I think it's most important: Culturally there's a world of difference. Safety is a part of Rust's culture . "Culture eats strategy for breakfast". Take sorting. In C++ the default sort is unstable, while in Rust the default sort is stable, that's just those defaults you mentioned (each has both kinds), although the choic…

The sibling says that C++ has the wrong defaults, full stop. Well in Rust the default `HashMap` uses a cryptographic hash, and you see it everywhere , it's the de facto community "default". In C++ the community "default" is `absl::flat_hash_map`/`folly::F14`, which use SIMD to compare a whole stripe of key-prefixes simultaneously. I want different defaults for different programs, but the idea that it's esoteric to ev…

In fact the crypto hash does not actually improve security. It is just slow.

So, the trade is just: slow for nothing.

Re: Safety: A comparaison between Rust, C++ and Go

#133

Post by ncmncm »

crabbygrabby wrote: post #49
ncmncm wrote: post #11

Disingenuous. The bad C++ code is in the very first line of the "make_appender" definition: capturing the closure's environment by reference is nonsense: It is equivalent to returning a reference to an argument. It is not, then, a closure at all. Using a correctly-defined make_appender would not, then, produce undefined behavior when you use it, with or without "move". What the author has done here was to take a too-…

It's possible the author actually made this mistake, and because c++ is C++ they didn't realize why/how. Not a lot of programmers have a good handle on c++, maybe even most don't... Hence these other languages.

If the author deliberately chose to compile with warnings turned off, in order to present an example that would crash, then that tells us more about the author than about the point.

Re: Safety: A comparaison between Rust, C++ and Go

#134

Post by ncmncm »

CrendKing wrote: post #44
ncmncm wrote: post #11

Disingenuous. The bad C++ code is in the very first line of the "make_appender" definition: capturing the closure's environment by reference is nonsense: It is equivalent to returning a reference to an argument. It is not, then, a closure at all. Using a correctly-defined make_appender would not, then, produce undefined behavior when you use it, with or without "move". What the author has done here was to take a too-…

The fact that you may know that make_appender definition being bad does not mean every C++ user knows as well. It's also impossible for you to know ALL the possible bad, UB leading C++ code out there. I think the point the author tries to make is that, while C++ and Rust are probably "the same" for the most skillful and disciplined programmers (such as you), for average human, Rust just catches way more errors they m…

Literally anybody can turn on warnings and heed the results.

Re: Safety: A comparaison between Rust, C++ and Go

#136

Post by ncmncm »

benreesman wrote: post #15
dataflow wrote: post #9

Earlier quoted context omitted.

> Unless clang-tidy has false positives, in which case the comparison isn't apples to apples then. Confused... so you're suggesting Rust's checks are somehow free of false positives? Doesn't the halting problem get in the way? One Rust-specific example: https://www.reddit.com/r/rust/comments/nr7a33/is_the_borrow_...

I find it so weird that the Rust community is borderline evangelical about memory safety when a) it's not actually memory safe once you start doing heavy shit b) modern C++ is quite memory safe and c) there are so many other great reasons to like Rust. Memory safety in serious systems software is something that you approach asymptotically and/or probabilistically. Rust makes it easier to be memory safe in a lot of sc…

Rust is "cool", lately. But it lacks basic features that enable capturing important semantics in libraries.

So the tradeoff is not relative safety against a little compile-time inconvenience. The tradeoff is against "no, you cannot code that thing at all, suck it".

So almost all discussion of relative safety (which Rust advocates would like us to think is absolute) carefully sidesteps the point that there is a very great deal that cannot be expressed in Rust at all -- and not because expressing those things would have been at all unsafe.

Re: Safety: A comparaison between Rust, C++ and Go

#137

Post by ncmncm »

vvanders wrote: post #104
jjnoakes wrote: post #78

Earlier quoted context omitted.

> a crashed program is a crashed program whether I dereferenced a null pointer or was poking around in a slice with multi-byte Unicode characters in it They aren't the same thing though, that's the point. Dereferencing a NULL pointer isn't guaranteed to crash. In fact if you are writing through the pointer, you may even have a security issue on your hands (rce, etc). Safe Rust may have runtime errors that "crash" the…

Yep, my favorite part of heap/stack corruption is not when it crashes immediately but rather when it rears its head 2-3 weeks/months later when some upstream call pattern or timing has changed. I've spend weeks chasing down single instances of this on multiple projects. The nasty part is you have no predictability in if it's going to be one that crashes immediately, silently writes garbage(hopefully not to disk!), is…

It has been years since I spent any time chasing down memory usage errors.

I recommend compiling with warnings turned on, and acting on them.

Re: Safety: A comparaison between Rust, C++ and Go

#138

Post by ncmncm »

tialaramex wrote: post #127
pjmlp wrote: post #126

Earlier quoted context omitted.

I have tried plenty of times, and seen not so happy train travelers with the same ticket for the same place on the same train, hence why bring it up all the time. It is obvious it is a subject that is irrelevant in the Rust community. Who needs consistency in distributed systems when multiple threads from the same process are accessing the same external data without coordination.

> Who needs consistency Programmers do. Programmers are human and so can't reason about the behaviour of non-trivial programs without sequential consistency. If I was trying to debug software which sometimes mistakenly issues people duplicate tickets, I think I'd want to be able to reason about how the software works, and that's not going to be possible if it doesn't even exhibit sequential consistency.

Your argument amounts to "Rust prevents X, so X is important. Rust cannot prevent Y, therefore Y is less important."

Re: Safety: A comparaison between Rust, C++ and Go

#139

Post by ncmncm »

blub wrote: post #119
benreesman wrote: post #2

Rust has a lot of great qualities that C++ lacks, but comparing `rustc` to `gcc` or `clang` on move-semantics checking is just kind of silly these days. `rustc` has `clang-tidy` built in. `clang-tidy` is not letting you mutate or even access that moved-from "suffix" object without throwing an error. It's annoying that you need `clang-tidy` and ASAN and shit to get comparable runtime safety even in greenfield C++, but…

Objectively speaking, Rust does not "have a lot of great qualities that C++ lacks". Any new feature or improvement has its pluses, but also its minuses. * Rust has traits, but does not support OOP. Architectures where OOP is particularly effective are proving to be a significant challenge for Rust - GUIs are the obvious one, but also game development Rust projects have to invent new approaches. * Option/Result make t…

More to the point, Rust lacks key features I need to capture essential semantics into libraries. So, the libraries I could write in Rust would be less powerful than libraries I can write in C++.

Among common uses for these more powerful features is to make misuse of the library into a compile-time error. Coding the library in Rust, if possible at all, would mean failing to prevent these usage errors.

The point here is that C++ puts more power in the hands of a library writer, and both the responsibility and capability to enforce safety in uses of the library. Rust jealously reserves maintaining safety to the compiler alone.

Re: Safety: A comparaison between Rust, C++ and Go

#140

Post by ncmncm »

vitus wrote: post #45

I feel like a better comparison would be to use std::span (C++20) to mimic Rust's slice. Otherwise you might be tricked into thinking that adding // hey don't pass in a temporary auto make_appender(std::vector && suffix) = delete; (which turns the provided code into a compiler error under both g++ and clang++) is adequate to prevent the immediate class of issues (namely, C++ allows const Foo& and Foo&& to bind to tem…

That would just be another tendentious example. Nobody would write a make_appender that takes a span argument, because it makes no sense.

The point we should take away is that is actually hard to invent plausible examples of the failure that we are being told Rust would prevent.

Post reply on HN