C++20 improves the situation, though. https://en.cppreference.com/w/cpp/utility/format/format

But yes, in a world where Rust exists, I don't see a need for C or C++ for greenfield.

There are plenty of greenfield use cases where Rust will need to bind to existing C and C++ libraries.

I guess the field I was imagining was greener than that. But yes.

In many cases you can just interface to the C libraries. But cross language coding has never been perfect, and yes, sometimes it's better to continue using the same language.

It's not hard to write an RAII wrapper around a C library, and the careful allocate/free is code you have to write either way (e.g. I'd write a wrapper in C++ if I need to use a C library with resource handling).

C is the easiest to interface with. Every language has to be C-compatible.

I would not choose C or C++ just because I depend on libfftw, or simdjson, or most other things. If the code that needs to talk to the library is less than 10% of the total program (exact percentage just made up), then I'd still use Rust.

So many of the CVEs against rust crates are actually against the bindings for things like ssl, glibc, and libcurl. I think accepting small growing subsets of ssl and curl for native implementation would be a good idea. And relibc too I suppose. Go went this route, and while it caused some headaches porting to new kernels, it has lots of benefits too.

Go has had to rollback on that decision.

Rust while much safer, also needs care if any crate makes use of unsafe, even in pure Rust.

https://thesquareplanet.com/blog/the-story-of-a-rust-bug/

Yes it is in the libc bindings, but the logic error is on Rust side.

That story seems to be about missing code/functionality, more than anything about a vulnerability. There is way more unsafe out there than there should be. Bindings are are one of the very few cases that must have it.

Just use bindings isn't always as easy.

It depends on the company, the team skills, the tools they are used to have, the difference when moving into Rust, eg CUDA in C++ with NSight and Visual Studio plugins from NVidia, versus Rust.

Yup. I feel that I left plenty of space for this use of case in my comment.

But as for team knowledge of C++, that's temporary. In the long run, because of the avoidance of many bugs, it may save time.

But there are also no silver bullets.

I mean you can just not use iostream? A lot of modern C++ projects just ignore it. For either C style IO or more C++ -y IO.

Yeah, but you can equally ignore fgetc and friends in C. My only point here is that IO in the standard library is not very good in either language.

IMO a parser should be reading the entire file, and then parsing as a block of memory, by default, for most use cases these days. That way you don’t have to think about IO while you are parsing. Streaming parsers are niche these days for good reasons.