Earlier quoted context omitted.
Dunno. Young devs can pick basic Rust constructs fast but when it comes to complicated stuff where performance is critical... There must be raw talent and lot of grind. IMO it's easier to write super complex stuff in C++ than in Rust as there are just too many cognitive things to keep in mind in Rust to even compile. C++ for talented folks makes life easier there. Like JavaScript, yet another language written for bad…
> in Rust as there are just too many cognitive things to keep in mind in Rust to even compile. That hasn’t been my experience. Rust (the language) doesn’t seem to get any more complex as programs get bigger. Lifetimes, while complex in isolation, tend to compose really well. Most of the pain of learning rust seems to be experienced up front. (Well, other than async but I don’t consider that ready yet). In comparison,…
It's time to halt starting any new projects in C/C++
331–340 of 929 posts
Re: It's time to halt starting any new projects in C/C++
#332You 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…
Re: It's time to halt starting any new projects in C/C++
#333Earlier quoted context omitted.
It's not. But to be fair it feels more ready than rust did at 1.0
Not to say I'm not excited for Zig, but there are still bugs, miscompilations, and many breaking changes planned. Communicate realistic expectations, lest you become the next language evangelism strike force.
Re: It's time to halt starting any new projects in C/C++
#334I 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…
In fairness, using integer handles instead of pointers is pretty idiomatic in high-performance C++ too. I've never found it to be onerous or complicated.
Re: It's time to halt starting any new projects in C/C++
#335Unless he means that Rust should be used on projects where the Rust compiler is available for all relevant platforms and C and C++ can be used otherwise, I disagree. In fact, until LLVM is replaced, C++ will probably be the language of choice for new languages. Even `rustc` requires a C++ bootstrap for that purpose. There are also other important C++ and C libraries that will continue to mean C and C++ may be better…
> In other words, it's possible to put C and C++ on the same footing as Rust when it comes to memory bugs; No. This is only true if you don't care about occasional bugs. e.g. hobby projects. But if you're talking about mission-critical or security-critical software, there is a gap - or a canyon - between C vs C++ vs Rust. And no amount of extra "efforts" by the programmer's part can bridge those gaps completely.
The code is my `bc`. [1]
Find a memory bug, any memory bug, in my `bc` after 1.0.
Rust has occasional memory bugs too; I mentioned that specifically. It still happens.
So if you really are correct, break my `bc`.
Re: It's time to halt starting any new projects in C/C++
#336Earlier quoted context omitted.
Dereferencing NULL pointers: my code is structured such that every function parameter that can be NULL is marked so. And I check those possibly-NULL pointers. This could also be done with a macro: #define y_d(p) ((p) == NULL ? abort(), *p : *p) Otherwise, the compiler (clang, usually) warns me when a NULL pointer is passed in and I have asserts to catch them. Even before I had all of this infrastructure, deferencing…
After looking at this, honestly, you should just use C++.
Re: It's time to halt starting any new projects in C/C++
#337Earlier quoted context omitted.
Because, little by little, C++ became "unlearnable". Long ago C++ made C a little bit more complex. Because there were already lots of C programmers that wasn't a big deal. But then it didn't stop. Little by little C++ grew into a monstrosity. A lot of people went along. I gave up. For new programmers to climb in 2-3 years a mountain that seasoned programmers took 15-20 years to climb is asking too much.
In what world is C++ harder to learn than Rust?
You can get comfortable with some idioms of C++, that's fine. Can you understand what any valid C++ code means? No. Such person does not exist, not even Bjarne.
Re: It's time to halt starting any new projects in C/C++
#338Earlier quoted context omitted.
In what world is C++ harder to learn than Rust?
This world - the one you exist in right now. I say that as someone that wrote C++ for 10 years before moving to Rust. Rust was by far easier. That said - that’s an extremely biased statement and I recognize that. I think it was largely the compiler that helped make it easier.
Re: It's time to halt starting any new projects in C/C++
#339Earlier 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.
> You don't need to know about about 6 different string types If you're working on a substantial C++ codebase you probably do, actually.
Re: It's time to halt starting any new projects in C/C++
#340Earlier quoted context omitted.
"Oh, and it's possible to make C as good as Rust", do you have some concrete advice documented somewhere? Thanks!
Probably write it in Rust first and make a direct C port based on it? (Or is there a tool do this automatically already?)