Earlier quoted context omitted.
Wut? Makes no sense to me.
They’re claiming the CTO of Azure doesn’t know enough about modern C++ to make the statement that we’re discussing. Bold claim.
It's time to halt starting any new projects in C/C++
551–560 of 929 posts
Re: It's time to halt starting any new projects in C/C++
#552Earlier quoted context omitted.
Just cus they add a feature to a language doesnt mean u have to use it. Though it does seem very few programmers are smart enough to stick to the most basic features whenever possible.
One problem here is that everyone ends up with their own little niches of the language that they like, and nobody's code looks like anyone else's, and suddenly to read a codebase you do need to know huge swathes of the sprawling language. At lastjob, we did a lot of C++, and I could tell whose code I was reading without checking blame because I knew who liked what idioms and features.
Re: It's time to halt starting any new projects in C/C++
#553Unless 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…
No one's talking about your personal project here. The audience is teams of people building software to be used in production.
Re: It's time to halt starting any new projects in C/C++
#554Blanket statements like this just show that people don’t understand why people stuck with a language. I worked in C/C++ for a long time, though it’s been a while now. I just went to look at whether Rust had any bindings for MPI. It does - rsmpi. But they’re not fully implemented, and only support a restricted subset of MPI implementations which are pretty much the latest versions. Some others might work, but it is no…
https://www.areweguiyet.com/ Until rust catches up with some meaningful feature set that Qt provides starting a GUI project in rust is probably going to be painful.
https://github.com/tauri-apps/tauri uses OS provided WebView
https://github.com/sciter-sdk/rust-sciter uses Sciter
Re: It's time to halt starting any new projects in C/C++
#555Earlier quoted context omitted.
There is still quite a lot that you can only ever express in C++. So, no. And plenty of that, you will never be able to express in Rust.
That's a bold claim (since both languages are Turing complete). I presume you meant safe Rust? But that's kinda the point. If something is memory tricky it is supposed to go into unsafe so you can make a safe abstraction around it. Unless you meant actually all of Rust. In that case, please share what's inexpressible in Rust.
At the most basic level, in Rust you cannot overload operators. You have no opportunity at all to code a move constructor. I could list off others all day long, but you probably would not understand most.
Then there are the things the borrow checker will not let you do, that would be correct, but it can't see that. You might say you can put those in "unsafe", but you can't really field a library where users sometimes must put a call in unsafe.
It is easy to insist you have never needed any of that stuff for your library, but that is really because you have constrained what you even think of trying to do by what you know you can do. We box ourselves in this way automatically, and it takes great effort to break out of such a mental box.
Re: It's time to halt starting any new projects in C/C++
#556Earlier quoted context omitted.
What's wrong with .cpp extension?
The implication is that he's mostly writing C despite the file extension suggesting they contain C++. C++ changed a lot over time, and the way modern code is supposed to be written is very distinct from "C with classes", but you still can do that if you want.
Many experts disagree with the way modern C++ evolves.
To say that modern code is supposed to use all the C++11-forward features or else it's obsolete is a massive bias on your part.
Re: It's time to halt starting any new projects in C/C++
#557I 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.
Rust's crates.io has over 15000 packages using async. Cloudflare has just replaced their nginx with a Rust proxy that uses Rust's async. Apple has hired Rust programmers for their storage and networking teams.
Rust has been out for 7 years now, and detractors on HN still treat it as an unproven novelty that's going to collapse any day now.
Re: It's time to halt starting any new projects in C/C++
#558This is a very long term strategy but it makes sense viewed that way.
Re: It's time to halt starting any new projects in C/C++
#559Earlier quoted context omitted.
They’re claiming the CTO of Azure doesn’t know enough about modern C++ to make the statement that we’re discussing. Bold claim.
I find it hard to imagine the CTO of Azure has done enough C++ programming in the last few years to be fluent in C++20. Maybe as a hobby I suppose; it doesn't match my understanding of what a CTO of a big organisation does otherwise.
Re: It's time to halt starting any new projects in C/C++
#560Earlier quoted context omitted.
There's nothing unsafe about integer indices because access to the array they index will incur bounds checks.
This means that you have array accesses that cause index out of bounds fatal errors instead of invalid pointer dereferencing that causes fatal segmentation failure errors. Detecting this kind of bugs reliably is a very good thing, but preventing such errors (and optimizing away bounds checking if possible) would be better.
Out-of-bounds array accesses causing segfaults is the happy case! The sad case is security vulnerabilities.