Hacker News Reader

Comment by totothetoro | Hacker News Reader

I like to think that people that brag about how good Rust is like the smell of their own farts. They just get nostrils full of methane every time they quiff one out. Rust replacing C and C++? That's not gonna happen in my opinion. I see Rust replacing C++ in the near future, but not C. C is by far the most flexible, yet powerful programming language I've seen, and no language can even come close to doing what C can. Let's not forget that C is very small and geared towards efficiency. How about instead of making a programming language bulky with tons of mechanisms to prevent human failure, we train humans to not be as prone to causing those failures? I love Rust but man are people smug about it.

View on HN

There was an article from Microsoft on why they're adopting Rust that was posted a little bit ago. The gist of it is that even with a skilled staff, 70% of their CVEs were due to memory errors.

Right - the whole point of having computers / machines is to reliably and efficiently do things that humans are bad at doing at scale. I honestly don't understand people who are excited about programming and also excited about doing things by hand that computers can do better and faster. Like, what is the appeal of programming to them?

Enjoying debugging their code? :)

The article was not from Microsoft but from some rag like ZDNet (I think it was also ZDNet, in which case they're currently submarine-ing Rust).

70% of CVEs are C/C++, because those bugs need to be fixed and important things run on C/C++.

It is an entirely useless metric.

ZDNet reported on a presentation given at a security conference by Microsoft.

> 70% of CVEs are C/C++, because those bugs need to be fixed and important things run on C/C++.

You mis-understood the statistic; the statistic was not "70% of CVEs come from C and C++", the statistic was "70% of bugs come from memory safety issues." They did not classify by language.

I kind of wanted to downvote you for being non-constructive, but instead, I'll ask you a question to try to make this a concrete discussion. Can you give a concrete example of "no language can even come close to doing what C can"?

(Not a statement about how C is flexible or powerful or portable or anything, a specific actual thing in C code.)

I'm a fan of Rust (although I haven't waded into it much yet), and a heavy user of C, and the one particular thing I find missing so far is a properly Rust-ified abstraction of QSBR-style RCU, with the full power and flexibility that can be achieved with liburcu-qsbr in C.

For C it's just some header files and a library and you get some amazing performance magic out of it. It's the key missing feature that makes me leery of going down the road of converting some existing C daemon code over to Rust.

It's hard to do low-level QSBR as a primitive for scalable threading in languages other than C/C++ unless you bake the abstraction in pretty deeply. I think it's probably possibly to bring it to Rust in a meaningful way, but probably non-trivial to integrate with all the other cool things going on in the language for concurrency and the borrow-checker, etc.

I'm not familiar with the implementation details of QSBR, and I've never used liburcu-qsbr, but what I've read about it tonight sounds a lot like the im[0] crate in terms of behaviour.

The behaviour in im is a data structure where readers get a reference that pins data in memory, so they have a consistent snapshot to read from. Any mutations made while there are outstanding read references will write to a new allocation for the part that changed, so the two references can share most of the data through structural sharing. When there are no outstanding read references, mutations happen in-place.

Have I correctly understood QSBR if I think it's similar behaviour to this? How does the implementation differ?

[0] https://docs.rs/im/13.0.0/im/

I’m not super familiar, but from a cursory google, it looks like crossbeam is the rust equivalent?

A valid point could be compiler availability. Almost every platform imaginable has a C compiler. Not a language feature though, just a sign of popularity.

Right, that's not an instance of "... language can even come close to doing what C can," absent an argument about how architectures that LLVM doesn't support are easy to write custom C compilers for but not LLVM backends. LLVM just happens not to support that many architectures today.

Also there have been a few attempts at a C backend for LLVM, and code in Rust that is compiled through C will generally retain its safety and speed properties.

Reply on news.ycombinator.com