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

61–70 of 188 posts

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

#61

Post by TillE »

benreesman wrote: post #10
estebank wrote: post #4

Earlier quoted context omitted.

Your point is a fair one, but defaults matter. There's little reason for clang-tidy not to be part of the default clang invocation by now, other than an aversion to producing new output for existing projects (that you could argue are already "broken"). Unless clang-tidy has false positives, in which case the comparison isn't apples to apples then.

Oh I completely agree that defaults matter, and I wouldn't advise anyone to go start some big C++ project unless they had a very good reason to. But Rust vs. C++ is not an apples-to-apples comparison in this regard: Rust got a clean slate and was willing to cut ties with engineer-millenia of existing high-value software to do it. In a perfect world Rust wouldn't be ambivalent at best and hostile at worst to C++ inter…

Given the vast C++ ecosystem (including pretty much every big game engine), there are still a ton of very good reasons to start a new big C++ project.

At least until Carbon is ready! But that's a few years away at the least.

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

#62

Post by zozbot234 »

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.

> it's pretty easy to get something past the compiler and tweak it until it works

That's just as true of Rust if you use clone(), Rc and RefCell. You just have to familiarize with a few boilerplate patterns, and the best part is you're only trading off a modicum of performance while preserving safety. But Rust can work quite well as a language for exploratory programming.

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

#63

Post by deeptote »

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.

This is the main reason that I use Go as my main language, and why many orgs are starting to adopt it: it's easy to read and jump into. I would argue, however, that it's very easy to create antipatterns and just general spaghetti code with Go. A language that's easy to be productive with != one that's also easy to maintain. Design and philosophy becomes very important with large codebases in the language.

source: consultant, seen some truly heinous Go monoliths.

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

#64

Post by zozbot234 »

benreesman wrote: post #24
estebank wrote: post #22

Earlier quoted context omitted.

Thanks, I'll look at pybind11. Have you looked at cxx by any chance?

I have. `cxx` and `autocxx` and `bindgen` and `cbindgen` are, better than nothing I guess? But they're all flakey and have weird corner cases (and crash sometimes! I'm looking at you `cbindgen`!) and don't handle containers well if at all and just, ugh. I always end up saying fuck it and `extern "C"`-ing everything. It would be completely possible to make these tools work well, but the Rust ethos is "rewrite everythi…

> But they're all flakey and have weird corner cases and crash sometimes!

Did you report those crashes? There's also crubit these days, mostly combining the autocxx and (c)bindgen approaches. (It's a very new effort, which is why it's being kept separate from these more established ones.)

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

#65

Post by arriu »

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.

I agree. However, my gut reaction was that the style of the go code was written differently than what I’d expect if asked to work off the rust version.

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

#66

Post by benreesman »

tialaramex wrote: post #48
benreesman wrote: post #36

Earlier quoted context omitted.

Again, this isn't a right/wrong thing. Rust moves by default (and a lot of people find "=" a weird pun for that), C++ copies by default and has rvalue-references and an explicit `std::move`. If you want copy in your C++ lambda, you start it `[=](...) {...}`, if you want take a pointer in your C++ lambda, you start it `[&](...) {...}`, if you want something trickier you do trickier stuff. Rust opts you in to the nitpi…

> 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 ever want an associative container within arms reach that fucking demolishes the other one is, ugh, God I want to like Rust even more than I do but this "we're right and everyone else hasn't seen the light" routine is infuriating and pushes me at least away.

My parent comment is trying to emphasize that this isn't a right/wrong thing, different tools for different jobs. And people are just like: "nope, everything but Rust is wrong".

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

#68

Post by [deleted] »

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-…

[deleted]

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

#69

Post by bsaul »

deeptote wrote: post #63
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.

This is the main reason that I use Go as my main language, and why many orgs are starting to adopt it: it's easy to read and jump into. I would argue, however, that it's very easy to create antipatterns and just general spaghetti code with Go. A language that's easy to be productive with != one that's also easy to maintain. Design and philosophy becomes very important with large codebases in the language. source: con…

There are definitely some ways to do bad designs in go, but i have the feeling it will be more immediately apparent what's wrong (or at least what part of the system needs rework). The reason being that there are no ways to obfsucate an awful design by wrapping it on mountains of generics programming and language sugar, making the whole thing a lot worse.

It's only my gut feeling, but does that match your experience ?

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

#70

Post by davedx »

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.

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 -- often in "only" front-end code.

I suspect that the adoption of Rust as a system language is going slower because that's just the natural pace of embedded/systems development, not because of anything intrinsic to Rust. There are now 30k+ lines of Rust code [1] in the Linux kernel. C++ can't claim that.

[1] https://www.phoronix.com/news/Rust-v6-For-Linux-Kernel

Post reply on HN