Rust is an alternative to C++ or C, not to Go, C# or Python.
Sure, you can write any program on any language, but if you try to write bare metal C code from C# or Python, your frustration will be quite large as well.
Use the right tool for the job.
Today Rust needs LLVM (written in C++), to generate binaries and it may be 2-3 decades before Rust will be used to write anything like LLVM with supporting platforms.
Today Rust library to do anything useful rely on unsafe integration with underlying C code.
Rust is still on fringes and quite a complicated language compared to C. I still doubt it will be a replacement for either, may be it will go-exist with C/C++ on fringes and may be in next 30 years if it survives like Python might have significant code and can be useful in place of C++.
Everywhere else C has been being replaced a good part of the last two decades, even all major C compilers are written in C++.
As for Rust, yes a co-existence is more likely.
You keep saying this, but I'd recommend you to look at a few random "C++" files in https://github.com/gcc-mirror/ for example.
For many of these projects, "moving to C++" often means to change the file extension. Or not even that, sometimes it's just changing the build setting to "Compile as C++".
There's no reason for holy wars. Fact is that regular C code is still ruling the world. Maybe not in the financial industry. Maybe it's embedded in a few C++ syntactic constructs. Maybe some people even found a way to use RAII in a way that doesn't suck in a large project. But the vast majority of the stuff that does something is still dangerous, evil, ugly C.
And now excuse me while I go watch another talk named "C++ Features to avoid" or "Taming build times in a large C++ codebase" or "Why we went back to plain C"
Here are my reading recommendations,
https://gcc.gnu.org/wiki/gcc-in-cxx
"This page is meant to eventually help document the ongoing effort in the "gcc-in-cxx" branch to make gcc compile in C++ mode, i.e. as C++ source code. So, the goal of this branch is to facilitate switching GCC's implementation language to C++."
https://devblogs.microsoft.com/cppblog/the-great-c-runtime-c...
> "We have converted most of the CRT sources to compile as C++, enabling us to replace many ugly C idioms with simpler and more advanced C++ constructs."
https://llvm.org/docs/Proposals/LLVMLibC.html
"Provide C symbols as specified by the standards, but take advantage and use C++ language facilities for the core implementation."
You are excused, write a blog post afterwards.
What you quote is not disagreeing with what I was saying at all.
Quick look at the GCC link you posted:
Project Status (last updated 06/2009)
Phase 1 of gcc-in-cxx now complete (06/2009)
gcc-in-cxx completes bootstrap as of 03/2009
> "Provide C symbols as specified by the standards, but take advantage and use C++ language facilities for the core implementation."
Sure, now let's look at the code
https://github.com/llvm/llvm-project/blob/master/libc/src/
Oh, it's not even a completed project. Here is stdio
https://github.com/llvm/llvm-project/blob/master/libc/src/st...
stdio/ for example has just 3, mostly empty files: file.h, fwrite.cpp, fwrite.h. Last commit was 8 days ago. It's not a project to be taken as serious evidence for any argument.
You need to stop selling things that might never exist, or have long been dead in the water.
Apart from that, I've looked at 10 files and the only use of C++ I've seen was some namespacing (that just makes the code more verbose IMO; YMMV).
It's essentially C, the thing you're leading a religious war against.
In this day and age where it's common knowledge that we're all living in opinion reinforcement filter bubbles, it should be possible to expect from people to at least quickly skim the citations they provide.
The Git repo matches that impression. There are neatly arranged directories containing CMakeLists and fuzzing stuff and READMEs and what not. Is there a good reason why strcpy() needs to be fuzzed? Some directories contain a lot of header files with 20 lines of comment junk and namespace junk, surrounding a single line that contains a function signature.
And looking at the code, it seems not even 1% of the actual functionality is implemented. I will be extremely surprised if this project gets ever completed.
Trying to reduce the amount of C code in the world since 1992, sometimes I win, sometimes I loose, in what concerns me, the outcome looks pretty much positive to me outside embedded development and FOSS UNIX clones.
As for the whole C compilers written in C++ thread, a proper reply will follow up rest assured, even if takes a couple of weeks like last time.
It's a bit more than that in the case of GCC. Not a lot more, but GCC does use templated containers. I'm not sure it uses any other C++ features, a kind of "C with templates" might have been sufficient for its purposes.
But then again, what would you expect? GCC is huge. What would a huge refactoring buy the developers?
Also just because it looks like C the semantics aren't the same, e.g. implicit conversions from void* aren't allowed in C++ compilers, ?: has a different precedence and a couple of other differences, this still in C89, let alone with everything that came afterwards.
void* not implicitly casting to their assigned value in C++ is an annoyance to me at best. I don't see any advantage at all there.
Things that matter are for example that C++ has vectors or other container types with the possibility to enable bounds checking with a compile flag. Well, you'd think they matter, because it is a security improvement at first sight, and I certainly thought so. I do now think that it makes programs significantly harder to maintain, to the point where superficial advantages cancel out or turn negative.
If that effect wasn't real at least to some extent, I wonder why do I see SO MANY function signatures in C++ projects where functions are passed in classic pointer + length style.
Furthermore tools like valgrind can be helpful in a way that gives some of the benefits of language-level methods for bounds-checking.
"CppCon 2015: Kate Gregory “Stop Teaching C"
https://www.youtube.com/watch?v=YnWhqhNdYyk
But what to expect when schools keep using Turbo C++ as teaching tool, https://galdin.dev/blog/why-you-shouldnt-be-using-turbo-c/
It's NOT a talk suggesting that C is bad or that the use of it is bad (despite the title).
It's a talk that suggests that C++ needn't be hard. If we were about actually understanding the language and making significant use of its features, Bjarne Stroustroup himself begs to disagree with the idea that C++ is a language that an individual can fully understand.
It's a talk suggesting how to approach teaching when the goal is to get quick (and surely limited) results instead of understanding.
But that's totally uninteresting to me. If it's interesting to you, we should end doing more comments, and I should try not to be annoyed when I read your evangelism and your ton of comments where you often hop around and quickly change topic when someone disagrees, and where you instead throw more links to pages that may have a title that suits your agenda, but that are often low on content or dead-in-the-water stuff, or that are completely unrelated to the discussion.
I'm tired of playing wack-a-mole with you.
As I mentioned above, templated containers is the one significant C++ feature that GCC uses. So maybe you now agree that it's not just C compiled as C++ after all?
My actual intention and the reason for my comments was to put things into relation. Compared to what you want to argue about here, pjmlp has a totally different idea of how things are or should be, and which I think is rose tinted and skewed.
Using a templated container once maybe every few dozen or hundred lines is not a justification for unfounded and unbalanced hating, and it is no indication for taking this codebase as an argument that C is so bad that they couldn't deal with it anymore, so they had to switch to C++ which solved all their alleged problems. That's just not the way it is.
Not taking from that technical point of agreement, and as an aside because I can't resist, I personally prefer to just use stay with C completely/"technically", and I believe I get better results by improving the architecture of my projects to work around C's "shortcoming" of not having templated containers. One can even make a point that just templated dynamic vectors are easily available in C since C does have polymorphism for arrays, supported by its pointer syntax, and using valgrind and the occasional assert() you can get lots of the same benefits in terms of security. The way I go about this achieves the same level of convenience, minus RAII (which I found to be problematic on larger scale. Templated containers and maps are nice though for short throw away code and temporary variables that never leave the function scope.)
I also actually make heavy use of a C99 feature that is still not in C++, which is designated initializers to make static arrays (often readonly data) to map from enums to additional data. I also found that I've wasted a lot of my time trying to build arbitrary "nice" things in C++ and always finding myself in a place some time later where I've totally locked myself in, so that's why I prefer just not to use a C++ compiler at all, even if there are some little nice-to-haves that you can get with it.
So there you go, my rant that is totally out of place here, why I don't think C++ is a better choice even if used very lightly.
Rust is not trying to replace any language.
> it may be 2-3 decades before Rust will be used to write anything like LLVM with supporting platforms.
Depending on what you mean by "like LLVM," this already exists partially in Cranelift. We'll see if it takes three decades or not.
Citation needed.
Rust lacks so many fundamental C++ "features" (variadics, thin pointers, HKTs, const generics, specialization, overloading, inheritance, good FFI with C++, C++ exceptions, ...), that trying to sell it as a C++ replacement is quite hard.
OTOH, Rust is pretty much at feature parity with C, having excellent interoperability with it, and only lacking somewhat in inline assembly, allocas/VLAs, etc.
You can take any C project, and implement a new feature or refactor some part of it in Rust without issues.
You can't do the same for C++ code easily: integrating with C++ templates is hard (e.g. try to use a C++ Boost library, or the C++ standard library from Rust), integrating with C++ error handling is hard (try to write Rust code that can error using C++ exceptions, or that can be unwinded with one), calling C++ ABIs is hard from Rust, interfacing C++ types with Rust is also hard (inheritance, virtual functions, etc.).
Any successful C++ projects that uses Rust (e.g. Firefox), uses Rust as a better C to implement a C library, that can be called from C++. That's not "being a better C++" in any way of the word.
It does lots of low-level things that are closer to C though.