When people use "C/C++" as a single language I usually know right away don't know much about C++. The distance between C and modern idiomatic C++ is many times larger than the distance between C++ and Rust. C++ looks like an ancient juvenile dialect of Rust compared to C and C++ looking almost nothing alike. You can write shit C++ that looks like C and breaks like C or you can write good C++ instead and end up with less (almost none in practice) memory problems also. This discussion comes up multiple times a week and almost never do the people having it actually know what they are talking about. I am aware this person is a big shot that has done great things, but it's still impossible he has seen actually good C++ written in the last 5 years. Not because it doesn't have memory bugs, because they are much harder to make. Language landscapes change and old languages die and new languages get popular, but it seems this whole thing is based on a giant strawman (that C++ is the same as C). It's very frustrating.
It's time to halt starting any new projects in C/C++
411–420 of 929 posts
Re: It's time to halt starting any new projects in C/C++
#412Earlier quoted context omitted.
> That said, almost every concept you need to understand C++ is also needed to understand Rust I agree that many basic C++ concepts are also present in Rust, but C++ is more than just its basic concepts: it's a huge set of features on top of those that interact with each other in complicated ways. Like how constructors aren't functions but something very special. If you just want to be a beginner C++ dev who works al…
Rust's "feature surface area" reaches or exceeds that of C++ through procedural macros, which surfaces the entire Rust AST to the developer. Major Rust crates like serde use this feature, and when it goes wrong the errors are actively misleading. I've personaly been bitten by this, it's incredibly frustrating to debug. https://serde.rs/derive.html#troubleshooting
I agree that debugging bad macros is annoying, especially proc-macros but that’s not comparable since by their very nature proc macros are no more powerful than hand written code. They cannot create new semantics, at best they can add new syntax sugar for things that already exist in the language.
Re: It's time to halt starting any new projects in C/C++
#413Earlier quoted context omitted.
Really interesting take, I've had the opposite experience. I've also seen very talented c++ devs screw things up in prod that rust doesn't even allow for. Really recommend taking it more seriously, it's fun once you get a handle on it. Also the tooling is really good now.
C++ has grown several language tools to let you write reliable, safe code. ... But it can't shed the old stuff without breaking backwards compatibility, and that's what bites you. The fact that smart pointers exist now doesn't stop a developer from passing around non -const char* with no size specifier and calling that a "buffer," and because the language is so old and accreted most of its safety features later, the…
The problem is that there is a lot of code and libraries using older patterns. And modern C++ is sufficiently different from the older C++ to constitute effectively a new language while still being unsafe. Moreover, in an attempt to address the efficiency the language has added views and ranges that provides more ways to corrupt memory. So why rewrite libraries in modern C++ when you can port them to Rust or Go and gain memory safety?
Re: It's time to halt starting any new projects in C/C++
#414I tried Rust about five years ago and I had trouble expressing cyclic data structures because there is no clear "owner" in a cyclic data structure. The "safe" solution recommended by the rustaceans was to use integers as references to the data in a vec or hashmap. I was rather put off by this: Instead of juggling pointers I was juggling integers. It made the code harder to debug and find logic errors. At least when I…
The answer today is to use a GhostCell
Re: It's time to halt starting any new projects in C/C++
#415You could say that Mark Russinovich is a hacker's hacker, the foremost Windows hacker, and a reverse engineering wizard. It was he who discovered and blew the whistle on the Sony rootkit scandal, for example, after finding and reverse engineering it on his machine. https://en.wikipedia.org/wiki/Sony_BMG_copy_protection_rootk... He extensively reverse engineered and documented "Windows Internals" details before joinin…
You seem to be quite well versed in the persona of Mark Russinovich.
Does he still develop the sysinternals tools? Does he program any more or has he settled into the life of an xTO? Rust, C++, what is he using? Did he port all his tools to Rust?
Given that his reputation is in other areas I don’t immediately see what makes his proclamation noteworthy. As someone that read his book and used his tools I’m more puzzled by his statement than motivated to spring into action :-)
Re: It's time to halt starting any new projects in C/C++
#416Earlier quoted context omitted.
You don’t have to know about exception safety, move semantics, meta-template higgery jiggery, or the 30 years of cruft that C++ has accumulated. Good riddance.
I think you DO have to know about those, or close analogs, in writing Rust. I like both C++ and Rust but I will rise to defend C++. 1. Exception safety becomes "catch_unwind." You might object that nobody cares about that, but major C++ codebases (Google, LLVM, Mozilla) don't care about exceptions; they are built with -fno-exceptions. 2. Move semantics in C++ are annoying, and so is the borrow checker. In Rust you ge…
"Hilariously awful" template metaprogramming is a thing of the past. It has been years since it seemed needed, or since I read any. New, more intuitive features have displaced it.
With concepts in C++20, you get to choose whether templates are duck-typed.
Re: It's time to halt starting any new projects in C/C++
#417Mark is not the subject. He is speaking of Rust and memory safety. I agree with him in general, that if a project requires C/c++ kind of capabilities then better to use Rust. But, if one doesn’t require Rust then I think one must avoid it by all means, because it’s such an investment into such a huge learning curve and such deep levels of complexity and mental burden.
Re: It's time to halt starting any new projects in C/C++
#418I think this is a silly idea. There are still loads of questions surrounding Rust. Especially about it's practicality... There are articles denigrating the likes of the trait and async systems on HN almost every day. And even ignoring that argument, any language is viable, so long as it can be used to build what you want to build.
Re: It's time to halt starting any new projects in C/C++
#419Earlier quoted context omitted.
You don't need to know about about 6 different string types, arcane borrow checker workarounds, RefCell complexity, massive async cruft - acquired by Rust in just 2 years. C++ will still be used heavily when Rust is buried 6 feet under and HN moves to the next hype language.
> 6 different string types have fun living your life pretending all strings are of the same type. spoiler alert: it's the wrong kind of fun. it's a bit easier if you're from a native English speaking country, but only until you get blown up by utf-8 (if you're lucky) in production.
[deleted]
Re: It's time to halt starting any new projects in C/C++
#420Fortran is still in use so im not worried that i use c++