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

31–40 of 188 posts

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

#31

Post by BoardsOfCanada »

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…

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".

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

#32

Post by jstimpfle »

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

    std::vector suffix{3, 4};
    auto append34 = make_appender(suffix);  // Version 1: test will work

    auto append34 = make_appender({3, 4});  // Version 2: test will fail
I was in a mood to type the examples but I accidentally made Version 1 because I had started with the author's first example. I wondered where the problem was and couldn't find any (neither running nor reading the code) until I noticed the author had changed to Version 2.

The problem is "obvious" in hindsight but one of the problems with C++ is that it makes certain things too implicit/convenient. I get that references are a staple feature in C++ but it's not at all obvious from the calling location that Version 2 is a bug. To see that, you have to navigate to the callee (finding which might be hard enough alone without a very solid IDE), and make sure that it's not capturing the argument by reference or not doing anything unsafe there.

It's often a problem when a seemingly "value" argument is turned into actually a pointer-to argument at the callee. There are other languages that have this too, and I've never liked it.

As someone who doesn't regularly code in C++ but has a solid understanding of the basics, I wonder why C++ ever allowed to have a reference parameter be called with a temporary? To me it feels like "References have value syntax but pointer semantics BUT you should program like it had value semantics"? Which to me would be exactly a premature optimization that is looking for trouble.

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

#33

Post by benreesman »

dannymi wrote: post #29
benreesman wrote: post #15

Earlier quoted context omitted.

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 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 isn't a startup business or (one hopes) a religion, or an MLM, or a home for sale. It's a useful tool among many.

Why do people say things like: "It's better not to dilute the message"? Better for who? That's sales/marketing language, not engineering language.

"The message"? Pardon my Francais, but WTF?

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

#34

Post by jstimpfle »

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…

>> In the end either safety is either important, or it isn't. Choose accordingly.

Not to disagree with your post but this comes across as very black-and-white.

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

#35

Post by dannymi »

jstimpfle wrote: post #34
dannymi wrote: post #27

Earlier quoted context omitted.

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

>> In the end either safety is either important, or it isn't. Choose accordingly. Not to disagree with your post but this comes across as very black-and-white.

To expand:

There's a prioritized list of requirements in engineering. Use the right tool for the job.

Rust has: (see https://hackmd.io/@rust-ctcft/r1plN4You#/5 )

1. Safety

If you don't need that at the first slot, then the biggest strength of Rust doesn't apply to your problem (and you would waste time having to track lifetime parameters more than necessary to solve your problem).

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

#36

Post by benreesman »

jstimpfle wrote: post #32
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-…

std::vector suffix{3, 4}; auto append34 = make_appender(suffix); // Version 1: test will work auto append34 = make_appender({3, 4}); // Version 2: test will fail I was in a mood to type the examples but I accidentally made Version 1 because I had started with the author's first example. I wondered where the problem was and couldn't find any (neither running nor reading the code) until I noticed the author had changed…

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 nitpicky static analyzer and you have to opt out with `unsafe`, in C++ you have to opt in with e.g. `clang-tidy` or some annotations.

They are remarkably similar, just with different defaults.

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

#37

Post by benreesman »

BoardsOfCanada wrote: post #31
benreesman wrote: post #15

Earlier quoted context omitted.

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…

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 a language: that cool software is written in it and is continuing to be written in it. This is a killer feature shared by Rust and C++ and these days to be serious about performant software in diverse settings, you pretty much have to know both well.

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

#38

Post by matheusmoreira »

BoardsOfCanada wrote: post #31
benreesman wrote: post #15

Earlier quoted context omitted.

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…

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".

> We'll see in a few years when more "heavy shit" has been written/rewritten in rust.

I'd really like to see that. Would be cool to see a completely new Linux user space written in Rust. Not necessarily a rewrite of existing software, new ideas would be great. I tested Linux system calls and they worked very well even though they needed experimental inline assembly functionality to work. With system call support, anything is possible.

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

#39

Post by estebank »

dannymi wrote: post #35
jstimpfle wrote: post #34

Earlier quoted context omitted.

>> In the end either safety is either important, or it isn't. Choose accordingly. Not to disagree with your post but this comes across as very black-and-white.

To expand: There's a prioritized list of requirements in engineering. Use the right tool for the job. Rust has: (see https://hackmd.io/@rust-ctcft/r1plN4You#/5 ) 1. Safety If you don't need that at the first slot, then the biggest strength of Rust doesn't apply to your problem (and you would waste time having to track lifetime parameters more than necessary to solve your problem).

There's also another item in that list, and that is performance. As soon as you slightly relax that one, Rust does become massively easier. A well placed .clone() or Arc makes the rest of the code performant enough and easier to understand, which makes the equation of choosing Rust over other alternatives in spaces that aren't necessarily systems programming less problematic.

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

#40

Post by dannymi »

benreesman wrote: post #33
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 isn't a startup business or (one hopes) a religion, or an MLM, or a home for sale. It's a useful tool among many. Why do people say things like: "It's better not to dilute the message"? Better for who? That's sales/marketing language, not engineering language. "The message"? Pardon my Francais, but WTF?

>Why do people say things like: "It's better not to dilute the message"?

>Better for who?

Better for everyone.

When talking about a new thing, it would be really silly to emphasize how nice the logo is, how nice the package it comes in is, look at the awesome tape the box is closed with etc. If I turn the product off it even turns off! Look at the nice rounded corners of the device!

It even can do async! Just like Javascript and .NET.

Who cares!

What is the main strength of the tool, the pain point it was made to eliminate? Lead with that.

> That's sales/marketing language, not engineering language.

Leading with the actual technical novelty that actually advances the state of the art in production compilers is marketing? Well, I guess it's good marketing in a way.

The user will find cargo on their own in 5 minutes.

Post reply on HN