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

91–100 of 188 posts

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

#91

Post by bbojan »

blakehawkins wrote: post #3
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…

And way, way better compiler errors thanks to a sane generics system

I think you meant thanks to a sane(r) macro system? Both Rust and C++ use monomorphisation for generics, I believe shitty compiler errors are due to C++'s templating.

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

#92

Post by benreesman »

CryZe wrote: post #84
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…

> In C++ the community "default" is `absl::flat_hash_map`/`folly::F14`, which use SIMD to compare a whole stripe of key-prefixes simultaneously. Just to be clear, the Rust HashMap does the same thing.

TIL. Thanks for letting me know that: https://doc.rust-lang.org/src/std/collections/hash/map.rs.ht...

I don't know how I missed this, is the Swiss port a fairly recent development?

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

#93

Post by andai »

agent281 wrote: post #76
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. Gl…

I don't write Go but it might have something to do with this:

https://go.dev/blog/declaration-syntax

Go's type syntax is unusual but supposedly much clearer when things get more involved.

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

#95

Post by throwaway17_17 »

bbojan wrote: post #91
blakehawkins wrote: post #3

Earlier quoted context omitted.

And way, way better compiler errors thanks to a sane generics system

I think you meant thanks to a sane(r) macro system? Both Rust and C++ use monomorphisation for generics, I believe shitty compiler errors are due to C++'s templating.

I’m what way can you have ‘generics’ in C++ that are not based on templating? I am almost certain that any implementation of anything ‘generic’ templates are inherently involved. Maybe I’m wrong about what you mean by generics though.

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

#96

Post by unsafecast »

dannymi wrote: post #27
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 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. If it is so bad, it should (in the sense of how things would be in an ideal world) not compile. >It is not, then, a closure at all. It is a closure because all variables are closed-over and there are no free variables in…

> If it is so bad, it should (in the sense of how things would be in an ideal world) not compile.

Yes, C++ can be a bad solution to a lot of problems, and that's okay. Use rust if you need a machine guarantee for memory safety (or you just like the language), you can use Go if you just don't care about that at all and want the language to take care of it. But you can use C++ for non-critical software that needs to be fast (games come to mind). Rust can be too much of a mental overhead than it's worth for some.

That closure is just not a good example. Nobody would write this, because when writing C++ code you _do_ think about whether you want a reference or not. Sure, a lot of bugs can happen but this is not, in my opinion, one of them.

If you want to prove a point, prove it fairly.

Note: I don't use C++ anymore, and I don't like it very much for other reasons.

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

#97

Post by jrajav »

TinkersW wrote: post #82

This would be a better article if the UB in the C++ example wasn't blindingly obvious-- no C++ programmer worth a damn would ever write this.

Why is this such a common defense for the peculiarities of C++? I see it pop up at least a couple of times, anytime C++ is criticized.

I don't have anything against taking pride in one's skill and craftsmanship, but excusing a tool's failings purely on the basis that one needs more skill to wield it and avoid those failings? I want to have that same level of skill and have my tool multiply my skill's output to the max, not have my skill wasted coaxing my tool to perform correctly.

If the implication is that the tool requiring more skill gives commensurate benefits, fair enough, but not if it's just hand-waving away obvious downsides.

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

#98

Post by ufmace »

dataflow wrote: post #20
estebank wrote: post #14

Earlier quoted context omitted.

There's a difference between code that used to compile no longer compiling because of an incorrect lint, and code that was never accepted. Rust is restrictive and gets less so over time. C and C++ need to become more restrictive over time, but that's a more traumatic direction.

What you're actually arguing seems to be "why I like Rust more than C++", not arguing why "clang-tidy has false positives, and thus the comparison isn't apples to apples then". Clearly the positives can be just as false in Rust as in C++. Your actual objection is that anyone arguing that any feature of Clang can measure up to the corresponding feature of Rust at present is automatically disqualified from making that…

I don't think it's about being tainted. It's that there's a bunch of C++ code out there already in Production in a ton of places that doesn't pass those checks, and may or may not actually be safe. It would be a ton of work that may not produce any end-user value for any C++ project to switch over to that.

Meanwhile, Rust has always had those checks, so there can't be any Rust code in Production that doesn't pass them that would be painful to switch over.

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

#99

Post by Narew »

benreesman wrote: post #37
BoardsOfCanada wrote: post #31

Earlier quoted context omitted.

I think memory safety is the killer feature of rust, and has become so because people see the real world problem it's solving, more than through evangelicalism. We'll see in a few years when more "heavy shit" has been written/rewritten in rust. My prediction is that they will have significantly fewer memory safety issues than comparable c++ "heavy shit".

From where I sit the killer feature of Rust is that a bunch of amazingly cool software is written in it, especially in the terminal. I'm a big terminal guy, and I can't think off the top of my head of anything I use constantly that isn't written in Rust. `rg`, `fzf`, `zoxide`, `bat`, `viddy`, the list goes on and on, I fucking love the shit people are writing in Rust. And I think that should be the killer feature of…

btw, fzf is written in go ^^

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

#100

Post by tialaramex »

pjmlp wrote: post #54
dannymi wrote: post #29

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 Most of the biggest advances in software engineering are because of increased modularity. One of the best traditional ways to increase modularity is the ability to define and call functions. But any isolation between these "function" modules is only possible if you can…

Rust's thread safety only applies to the special case of those threads accessing in process data segments. Rust's type system can do very little to help when those threads are accessing the same record on a database without transactions, OS IPC on shared memory, manipulating files without locks, handling hardware signals, handling duplicate RPC calls,... Yeah but that ultimately requires an unsafe block, kind of true…

This has been a recurring theme from you, but in the cases you're describing the risk is only a race condition (no general solution is possible) and not a data race (which safe Rust is able to deny by design). These are categorically different problems.
Post reply on HN