Live data from Hacker News

It's time to halt starting any new projects in C/C++

twitter.com

551–560 of 929 posts

Re: It's time to halt starting any new projects in C/C++

#551
post #534

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.

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++

#552

Earlier 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.

Wouldn't that mean there should be no competing crates, because people should write the same code for the same task?

Re: It's time to halt starting any new projects in C/C++

#553

Unless 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.

Gavin's personal project is being used in production.

Re: It's time to halt starting any new projects in C/C++

#554
post #499

Blanket 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.

Most GUI apps don't need what Qt provides though. They mostly need stability and cross-platform support, so ... they should start with something like Tauri or Sciter, and if there is something they need natively they will be in a much better situation to pick their poison.

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++

#555
post #474
post #410

Earlier 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.

No. I mean that there is a great deal C++ can capture and present in a library that cannot be expressed in Rust. Much of this will never be in Rust because of this or that early choice of direction.

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++

#556
post #517

Earlier 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.

>the way modern code is supposed to be written

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++

#557

I 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.

There's very little overlap between HN commenters lamenting about colors of async functions, and actual Rust programmers writing async software.

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++

#558
This makes more sense to me than trying to bring memory safety to C++. C is mostly frozen, do that with C++ and deprecate both. 50 years from now they will still be around but compatibility will be good due to the freeze. Everything new will be much safer and maintainable.

This 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++

#559
post #551

Earlier 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.

He doesn’t need to be fluent in every language to set technical direction as a CTO. You don’t question a general’s war strategy simply because they aren’t accurate with a rifle.

Re: It's time to halt starting any new projects in C/C++

#560
post #484

Earlier 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.

That's good! That's what you want.

Out-of-bounds array accesses causing segfaults is the happy case! The sad case is security vulnerabilities.

Post reply on HN