Safety: A comparaison between Rust, C++ and Go • Hacker News Board

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

#71

Post by mattgreenrocks » Sat, Jul 30, 2022, 2:51 PM UTC

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…

I like and use both C++ and Rust. I also have plenty of bones to pick with both languages.

However, I’ve never gotten the sense that Rust itself promotes the idea that “everything except for Rust is wrong.” I also don’t read much on the Internet these days, and I’m not doing so, probably avoid much of the hype that people are pushing about Rust.

Since it has been established as Hot New Thing, there are huge social incentives tied up in promoting it.

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

#72

Post by bhaak » Sat, Jul 30, 2022, 2:51 PM UTC

benreesman wrote: post #46

CrendKing wrote: post #44

Earlier quoted context omitted.

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…

Not to disagree necessarily, but if you (give me a little rope) bucket languages that are hard to get past the compiler but more often correct when you do (Rust, Haskell), and languages where it's pretty easy to get something past the compiler and tweak it until it works well enough for your purposes (JS, C/C++), the tweak-it-until-it-kinda-works languages are fucking killing it on adoption.

Javascript‘s adoption has much less to do with its language features but with its unique positioning.

There was (and still isn’t) a competitor that can compete on the same level with Javascript in the browser.

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

#73

Post by qsort » Sat, Jul 30, 2022, 2:54 PM UTC

eganjs wrote: post #58

qsort wrote: post #12

Earlier quoted context omitted.

"final" in Java is kind of useless, really. A const mechanism like C++ has would go a long way and would be a perfect fit for the OO nature of the language.

Final in Java means the value of a variable, property or parameter will not change after its initial assignment. Values in Java can be either a reference to an object or a primitive such as an integer, double or bool. It's definitely far from useless as it asserts that the reference or value you capture in a closure is not an old version that has been replaced, this approach is a consequence of Java disallowing arbit…

I agree with that and I use final as much as possible. E.g. instance variables that don't need to change, I almost religiously declare them as "final" and initialize them in the constructor.

What I mean is that what Java really "should" have is const like C++. A C++ function with a prototype of:

    int doSomething(std::vector const &x)

tells me much more than the equivalent Java:

    int doSomething(final List x)

Also C++ member functions can declare themselves as not modifying their "this" instance. E.g. there's no way to write this code in Java:

   int X::doSomething(std::vector const &x) const {
       ...
   }

which is an extremely powerful, compile-time checkable description of what we are doing.

It's not that final is useless (probably wrong choice of words there), what it does is okay and it's correct to use it as much as possible, but it's a far cry from the static guarantees afforded by const-correct code.

I also agree that the correct approach is immutability by default, but that ship has sailed, and it's also an orthogonal concern to what I'm saying here.

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

#74

Post by DmitryOlshansky » Sat, Jul 30, 2022, 2:58 PM UTC

The fact that the GC “owns” all of the memory happens to help a lot with lock-free stuff.

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

#75

Post by [deleted] » Sat, Jul 30, 2022, 3:09 PM UTC

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…

[deleted]

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

#76

Post by agent281 » Sat, Jul 30, 2022, 3:12 PM UTC

kcartlidge wrote: post #59

Totally not the point of the article, and totally subjective I know, but to me the thing that jumps out is how much more readable the Go code is than the others.

Definitely subjective. I don't find some parts very readable. E.g., this line took my a minute to parse:

  append34 := func() func([]int) []int {

If I was going to rank the readability I would say:

1. Rust function bodies 2. Go code 3. Rust function signatures 4. C++ code

Which you could argue is me shifting the boundaries a bit, but sufficiently statically typed languages seem to develop two (or more) sublanguages. Global complexity definitely pushes Rust down peg.

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

#77

Post by benreesman » Sat, Jul 30, 2022, 3:12 PM UTC

davedx wrote: post #70

benreesman wrote: post #46

Earlier quoted context omitted.

Not to disagree necessarily, but if you (give me a little rope) bucket languages that are hard to get past the compiler but more often correct when you do (Rust, Haskell), and languages where it's pretty easy to get something past the compiler and tweak it until it works well enough for your purposes (JS, C/C++), the tweak-it-until-it-kinda-works languages are fucking killing it on adoption.

I dunno man. I've done C, C++, JavaScript and TypeScript professionally for significant chunks of my career, and the trend that I've observed has overwhelmingly been towards stricter compilers. For example in the front-end world, TypeScript has absolutely exploded in adoption. Everyone could be still using JavaScript, but companies from startups to huge corporates have explicitly decided they want compile type safety…

Oh I think we probably see largely eye-to-eye. My weapon of choice when there are no other constraints is Haskell, and one reason I really like Rust is that I can get a lot of the Haskell features I like in a highly-performant setting. Most of the C++ I maintain these days is in whole or in part generated by Haskell. And if I have to write something fast by hand and it doesn't need to link to stuff I need, I reach for Rust generally.

I was also unaware that Rust has such significant penetration in the Linux kernel, and that's a place where I can see it really shining.

My first comment in this thread was something to the effect that Rust has tons of great stuff to offer, and that the memory safety argument is actually weaker than people think and probably not the only thing people should talk about.

The resulting gang-tackle is just one more data point that the community is still too small and evangelical for me to want to get involved past my proprietary Rust stuff.

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

#78

Post by jjnoakes » Sat, Jul 30, 2022, 3:13 PM UTC

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…

> 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 program but this is a controlled, well-defined termination, and there is no way for the execution state itself to be corrupted like in C++.

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

#79

Post by jeffbee » Sat, Jul 30, 2022, 3:17 PM UTC

There's a solid argument in here but it feels like there must be a better example. Can we think of a function that does something worth doing, in a way that programmers of all these languages would actually use, and that sets a subtle trap for C++ programmers? When I read this article all I see is a useless function that contains a completely obvious trap which, yes, Rust prevents, but also just thinking at all would have prevented.

Another small thing: the C++ in this article looks weird to C++ programmers because it qualified vector with std, but does not qualify move.

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

#80

Post by hkalbasi » Sat, Jul 30, 2022, 3:18 PM UTC

kcartlidge wrote: post #59

Totally not the point of the article, and totally subjective I know, but to me the thing that jumps out is how much more readable the Go code is than the others.

Can you mention the difference that made Go code is more readable than C++ and Rust?