Hi, I have been using C/C++ and Rust for a while but i did not go deep enough to read the code of gcc or rustc. So i want someone who is experienced in both Rust and C/C++ and have read the source of the compilers to help me find the answer for the following question.
Why did some people create a new language like Rust instead of improving gcc and adding those security checks in rustc into the gcc compiler ?
There are a lot of reasons you might want to create a new programming language instead of adding new features to an existing language. This particular topic (C++ versus Rust) tends to spark a lot of religious wars, so I'll try to outline some general contributing factors:
One should not confuse a programming language with any actual compiler for that programming language.
A programming language is a syntax and semantics defined by some specification. As you likely know C and C++ are defined by their ISO standards documents. Rust also has a specification somewhere (I know not where). Or at least it is defined by what we find in the Rust Book and other places.
Given such specifications one can write compilers for the languages. There are hundreds of compilers for the C language besides GCC. There are quite a few for C++. For example GCC, Clang, MSVC etc.
With that in mind your question might become "Why create a Rust language specification rather than add the features it offers to existing specifications of C or C++ or whatever else"
The first thing that comes to mind is that if one added Rust's strict type checking to C or C++ it would break pretty much every program ever written in those languages. No C or C++ user would adopt that new standard.
Similarly for Rust's lifetime checking.
Then there is the the issue of "bloat". C++ is already so encumbered with features that I don't believe any single human understands them all and how they work together. Adding more complexity to the language to add Rust like features would be totally over the top.
I'm no programming language designer but it seems clear to me that no language can support all features people want. Language features have to work together nicely. Just adding this or that feature with out thinking how it will work with everything else is likely going to result in an unusable mess.
Finally, a personal and perhaps odd observation after decades of programming in all kind of languages, I suspect that all experienced and talented programmers eventually begin to think that whatever language they use sucks. So, given their talents they set about designing their own programming language to relive them of the pain they have endured.
Which accounts for why we see programming languages sprouting like weeds all the time.
@Michael-F-Bryan and @ZiCog have given really awesome answers.
My take would be as follows: If you want to add the features that make Rust unique (the memory safety model, coupled with the generics model) into C++, it would be flatly impossible to do it in a way that is backward compatible. Either it would end up breaking most C++ programs, or we would have to cut down the feature so much that it won't be of any use.
One of the main reasons why people including me loves Rust is that it doesn't have certain features the C++ have(I'll not list them as that's not the point). Removing features from widely used language is practically impossible. Only Apple can do so with their own language.
I find all this fascinating. Back in 1996 or so I read Stroustrup's book " The Design and Evolution of C++" when I was first getting into C++ having used C for a long while. In it he discusses C++ features and why they are specified as they are.
Throughout the book I was constantly wondering why such and such a feature had been specified in what seemed a less that good way, when the obvious and nicer way had been rejected. Each time Stroustrup explains the reasoning, mostly to maintain compatibility with C. Often to fit with other new C++ features that in turn were less than ideal dues to the desire for backward compatibility. I bought it all, hook line and sinker. Stroustrup had done the right thing, it had to be that way, we could live with the resulting clunkiness, surprises and less than pretty code.
Decades went by... That process continued as C++ accrued more and more features in less than sensible ways. Justified by that backward compatibility goal. Resulting in the huge, unfathomable, language we have today.
Now, I don't say all the above to bash on C++ in particular. It's just that I worry for the future of Rust and indeed other languages. There seems to always be a relentless pressure on a language to add more features. In the name of making this or that more expressive in some situation or other. Or just bringing features that users of other languages are used to from their former language.
I feel this is more than a bit unfair to Stoustrop and C++. I can see myself making all the same over-engineering mistakes (multiple inheritance!), and it's hard to argue C compatibility when it's likely the main reason for it's success.
Further, while C++ has in the last decade started accruing lots of large complex features, the general theme and net effect is to supplant and simplify existing unnecessarily complex code patterns. This is extremely good, given the huge amount of existing C++ out there needing to be maintained.
For all the grief people give language committees, I've actually been very impressed by the choices and progress made by the big ones (C++ and Ecmascript. Any notable others I'm missing?) Perhaps the difference is when they're made up of the people actually using the language, and not people hired to create marketing bullet points!
That said, C++ would never have gotten something like lifetimes through in any reasonable timeframe, and they would most likely not have anything like the value they do in Rust. Now they have a successful example, so the chances are a lot better. Not good, but better.
It might be because I am not a computer scientists—I am a mechanical engineer who uses programming to solve mathematical problems, essentially—but Rust feels like the first compiled language that offers something truly unique as an experience. I mean, I can, for the first time, focus on the math and ignore the memory safety and most undefined behaviours.
I think this uniqueness would be VERY disruptive to add into C or C++... After reviewing their code, I have find myself telling people right away that they would not like Rust. They are quite good at keeping note of their pointers, allocations, and so on; and they use that to their advantage. (Some may argue that they will make mistakes nonetheless... but let's leave that for another discussion).
My point is that bringing the uniqueness of Rust into C++ will make of the latter a completely different language, and many of its users will not see that as an improvement but as a fundamentally horrible paradigm shift.
I feel the same. Except it's not quite the first, Algol did it back in the day and Ada specifically designed with correctness in mind.
Oddly enough some months ago I heard Bjarne Stroustrup taking about this at some C++ conference, he said that Rust like lifetime checking would be coming to C++ and that they could do it better. He gave no hint as to what that might look like.
As soon as you change something in C++ in a way that makes it not compatible with existing C++ codebases and/or compilers, then it's not C++ any more.
So that leaves you the options of:
staying compatible with existing C++ code, which requires keeping all old C++ features, including the "bad" ones, and only carefully adding optional new features on top. This is what the ongoing C++ language evolution does.
breaking C++ compatibility by changing or removing unwanted behaviors. But as soon as you can't use C++ compilers and can't compile other C++ code, it doesn't matter how much incompatible you are. At this point you can as well make a new language without legacy features or confusing not-quite-similarity.
For example, Rust wants to have a different meaning of references which is very incompatible with C++ references. Just that one change is enough to completely break compatibility with all non-trivial C++ code, so majority of existing C++ users wouldn't be interested in using a "C++ except all references behave completely differently" language. Rewrite of C++ code from "classic" C++ references to borrow-checked references would be almost as much work as a rewrite in Rust.
I completely agree with the existing answers and have nothing to add to the main thrust of any of them, but:
For completeness, the most concrete serious proposal I ever saw for a "C++ borrow checker" is
but I've heard nothing about it in the years since I posted that, despite looking around a bit, so I have to assume it didn't go anywhere. Still, it's instructive to see how far backporting lifetime checks into C++ can get without breaking all of the code ever.
In case you haven't read this yet..
Graydon said
I'm a language engineer by trade and usually this means I'm working on compilers or tools for other languages I didn't have any part in designing. Naturally this sort of thing leads a person to sketch their own hobby projects. I've been doing so for a long time and finally decided to show one such prototype I'd been working on in my spare time to my manager at the time. Mozilla took an interest and set up a team to work on this language as a component of longer-term project to rebuild their browser stack around safer, more concurrent, easier technologies than C++. That larger project is called "servo". Mozilla is funding Rust development because of that.
from...
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.