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

51–60 of 188 posts

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

#51

Post by pjmlp »

estebank wrote: post #4
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…

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.

They do, that is why any C++ shop where code quality is relevant has a DevOps team that cares about the right defaults being enforced on th CI/CD pipeline.

Devs that don't care only get to build on their own computers.

It isn't fullproof, but definitely helps to tame some cowboys.

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

#52

Post by pjmlp »

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

Business also needs to care,

> Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law.

-- C.A.R Hoare on his Turing award speech in 1981.

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

#53

Post by pjmlp »

matheusmoreira wrote: post #38
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".

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

Once upon a time there was a project to do a Linux distribution in Ada.

Unfortunately it died a couple of years later.

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

#54

Post by pjmlp »

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'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, except no one reads the code of all crates they depend on, and the direct dependencies might be safe in what concerns the direct consumers.

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

#55

Post by keithalewis »

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…

"Doctor, it hurts when I do that!"

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

#56

Post by touisteur »

benreesman wrote: post #19
estebank wrote: post #17

Earlier quoted context omitted.

Rust isn't hostile about C++ interop, it's that between native interop (which requires dealing with templates and memory unsafety) and safety, Rust prioritized safety, while Carbon is trying the alternate approach. The behavior of C++ is simply hard to interface with while providing the assurances Rust gives you. Edit: how many languages have native C++ interop that supports the whole language? Would love to hear of…

I said ambivalent to hostile at worst, and I'm sorry, it is. I write FFI to C++ in Rust, Python, and Haskell practically every week, and Rust C++ sucks. Slap it in an `unsafe` block, fine. But let me move a `std::vector ` into my `unsafe` block easily. Erase the types, fine. But let me call `v.at(idx)`. Python takes C++ interop seriously, which is why Tensorflow and PyTorch and all the other people trying to script g…

I wouldn't say python takes C++ interop seriously, it's more like the pybind11 people are amazing at what they do and found a way to slice the problem neatly. But yes, it's night and day, pybind11 is a godsend.

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

#57

Post by ChadNauseam »

dannymi wrote: post #40
benreesman wrote: post #33

Earlier quoted context omitted.

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

Even if rust wasn’t memory safe, being C++ with traits and ADTs would be enough for me to use it. Those are important safety features!

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

#58

Post by eganjs »

qsort wrote: post #12
jiehong wrote: post #5

Java falls a bit in between Go and Rust on that example: Closures only allow variables that are effectively final, aka you can’t reassign them (the compiler will stop you). But you could pass an object and update its internal state.

"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 arbitrary pointers. IMO Java's biggest mistake here is mutability by default, which Kotlin has learned from. If you understand why it is this way it makes a lot of sense and tbh I think it promotes better code. That said I would like to see more immutability in Java and with things like Record classes you can see Java is moving in the right direction.

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

#60

Post by grumpyprole »

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.

> the tweak-it-until-it-kinda-works languages are fucking killing it on adoption.

Industry clearly prioritises speed of delivery above all else. Security, reliability and maintenance are future problems (that would be nice to have).

However, in order to gain the power to reason about our code and be able to prove the correctness of various properties (what a typechecker does), we have to program with more restrictive models. This has been argued many times before (e.g. Dijkstra's structured programming). Haskell and Rust are just two of many examples. My favourite is regular expressions, choose actual proper regexes and you have guaranteed O(n) execution, choose Perl/Python "Regex" and you have a potential security hole.

Post reply on HN