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

151–160 of 188 posts

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

#151

Post by accountofme »

infamouscow wrote: post #102
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…

It's not just C++ interop. We chose Zig because writing C library bindings for Rust is bewildering.

the first thing i did in rust was c lib bindings and it is simple.

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

#152

Post by infamouscow »

accountofme wrote: post #151
infamouscow wrote: post #102

Earlier quoted context omitted.

It's not just C++ interop. We chose Zig because writing C library bindings for Rust is bewildering.

the first thing i did in rust was c lib bindings and it is simple.

The C library we need has a few requirements that most people agree are difficult for Rust.

Working with any of the following is a nightmare:

- Memory arenas

- Intrusive data structures

- Buffer lifetimes with interesting lifetimes (typically because it maps to hardware)

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

#153

Post by benreesman »

unsafecast wrote: post #124
benreesman wrote: post #111

Earlier quoted context omitted.

Ideally we'll just be able to open source it soon! Basically we have a nice Haskell DSL for generating arbitrary C++, and we deal with lots of code you wouldn't want to write by hand (big nested switch statements and other kinds of state-machine logic, choices about loop unrolling, lots of template overloads, SIMD intrinsics that require immediate values, etc. etc.) so we write Haskell that generates C++ and feeds it…

Sounds great, that's what I was imagining too. Is there a way I can find it when/if you open the source?

Drop me a line at ben@rocinanteresearch.net and I'll let you know when we can open-source some of it.

None of it is really all that magical btw, so you should take a whack at it yourself!

One thing that wouldn't have occurred to me that one of the Haskell geniuses I work with identified to use is the notion of a "free"/"operational" monad: https://apfelmus.nfshost.com/articles/operational-monad.html.

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

#154

Post by unsafecast »

benreesman wrote: post #153
unsafecast wrote: post #124

Earlier quoted context omitted.

Sounds great, that's what I was imagining too. Is there a way I can find it when/if you open the source?

Drop me a line at ben@rocinanteresearch.net and I'll let you know when we can open-source some of it. None of it is really all that magical btw, so you should take a whack at it yourself! One thing that wouldn't have occurred to me that one of the Haskell geniuses I work with identified to use is the notion of a "free"/"operational" monad: https://apfelmus.nfshost.com/articles/operational-monad.html .

Thanks a lot.

> None of it is really all that magical btw, so you should take a whack at it yourself!

Of course! It's always good to see how other people approach it though.

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

#155

Post by ncmncm »

rmadriz wrote: post #147
ncmncm wrote: post #143

Earlier quoted context omitted.

The point missed everywhere is that Rust lacks key language features needed to capture essential semantics in libraries, that C++ provides. To code libraries I want to code, I cannot use Rust. Rust cannot express them. So, safety, good , fast enough, good , but insufficiently expressive? No, thank you.

can you elaborate on those key missing language features ? You have commented multiple times about that, but haven't seen you giving any concrete example. I'm Genuinely curious.

Where to begin? Operator overloading. Programmed move semantics. Generics argument concepts. Look at the whole list of features C++ got since C++11, and subtract out the few of those Rust had or got.

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

#156

Post by jjtheblunt »

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 honestly don't think i've seen "cool async stuff" as a substring before.

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

#157

Post by kcartlidge »

hkalbasi wrote: post #80
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?

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

Probably not, and to be fair anyone else's preference is equally valid. I think largely what individuals consider most readable depends less on what's being read and assessed now, and more on what route a developer has taken to reach this point in their career.

If I'm honest it's more about unconscious familiarity with idioms and constructs than it is an isolated unbiased opinion.

And I'd probably also change my comment slightly to say that by "Go code" I really did mean the actual code doing the work; I find the tests far less appealing.

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

#158

Post by estebank »

nyanpasu64 wrote: post #125
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…

rustc rejects the resulting program if you mechanically factor out a function accessing &mut self, into a function holding mutable borrows to half the fields calling another function which access the other half of fields (or vice versa, the caller holding &field calling a method mutating other fields). This requires the more complex transformation of passing individual fields into the subfunction (more work, but some…

The third option is to use a wrapper type with internal mutability, but that is to be done very sparingly.

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

#159

Post by estebank »

ncmncm wrote: post #139
blub wrote: post #119

Earlier quoted context omitted.

Objectively speaking, Rust does not "have a lot of great qualities that C++ lacks". Any new feature or improvement has its pluses, but also its minuses. * Rust has traits, but does not support OOP. Architectures where OOP is particularly effective are proving to be a significant challenge for Rust - GUIs are the obvious one, but also game development Rust projects have to invent new approaches. * Option/Result make t…

More to the point, Rust lacks key features I need to capture essential semantics into libraries. So, the libraries I could write in Rust would be less powerful than libraries I can write in C++. Among common uses for these more powerful features is to make misuse of the library into a compile-time error. Coding the library in Rust, if possible at all, would mean failing to prevent these usage errors. The point here i…

Could you elaborate on this?

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

#160

Post by arinlen »

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.

> Your point is a fair one, but defaults matter.

This sort of comment is far from fair and misses the whole point.

The thesis of this article is how programming languages compare with regards to safety.

It makes no sense at all to compare particular implementations and try to pass personal assertions on particular features of said implementations as broad assertions about the programming languages they support.

So a particular Rust implementation is bundled with a linter. That's pretty convenient.

It just so happens that the linter is provided by a compiler stack that is also one of the main reference implementations of C++, and said linter also supports C++.

Is it fair to thus claim Rust is somehow superior to C++ just because a particular implementation enables by default it's linter on Rust code but not C++?

> There's little reason for clang-tidy not to be part of the default clang invocation by now

It's perfectly fine that anyone forms their own personal opinion on what defaults a tool should ship with.

That says anything nothing about the programming languages and their safety though.

Post reply on HN