If people treated C++ as a maintenance-only language and used it only for legacy code -- like COBOL -- the world would be a better place. The world would also save billions of dollars.
This is not a matter of RAII or "smart" pointers (which are not even smart enough to deal with cyclic references unless the programmer explicitly breaks the cycle). It is a matter of a language whose high-level features are constrained by low-level concerns, where the features compose poorly, and where things that are obvious (like requiring that functions with a non-void return type have a return value along every control path) are simply omitted from the standard. It is dizzying to think of how much money has been spent on bugs that were made possible by C or C++; why are we continuing to waste time and money on these languages?
You're ignoring the cost of actually running the applications in question. The benefits of reduced development costs can quickly be negated if performance starts to suffer.
We see this a lot with Ruby on Rails web apps, for instance. Perhaps they're quicker to develop in many cases, and maybe they're slightly less vulnerable to certain problems than C or C++ apps are, but they are much less efficient at runtime.
This inefficiency becomes visible when more hardware, or more powerful hardware, is needed to run such web apps. This inefficiency further becomes evident when users (it's worse when they're highly-paid employees) have to literally sit and wait for the web app to do its work. Over time, these costs can add up significantly.
It can be even worse for applications that are running on millions of systems. Even slight performance decreases can sum together to be very costly at such a scale.
C and C++ are still unmatched when it comes to producing efficient applications, both in terms of CPU usage and memory usage. Languages like Go and Rust may get close, but that'll be far in the future, if ever. I think it's safe to say that scripting languages like Perl, Ruby and Python will, in general, never be as efficient as C or C++.
Maybe you see C and C++ as a "waste of time and money", but they bring significant cost reductions for many of their users. That's why they're still being used today, and while they'll be used for a long time to come.
Yeah but in high performance web app the real competence for C and C++ are JVM languages (Java, Scala, etc.), not Ruby and Python. Twitter switched from Ruby to Scala/Java because Ruby performance was terrible.
Could they have used C/C++ for better performance? Yeah, but Java was goodEnough and for most high performance web apps it is GoodEnough, the cost being some more money for hardware (for Ruby and Python the cost is a lot higher and sometimes not even with expensive hardware you can solve the problems):
Just like C++ became GoodEnough and people switched to it from C for high performance apps, just like C became GoodEnough and we switched from assembly to C.
>If people treated C++ as a maintenance-only language and used it only for legacy code -- like COBOL -- the world would be a better place. The world would also save billions of dollars.
Citation needed. This is a wishful thinking idea that ignores tons of pragmatics in application development.
If all people started writing code in a modern C++ equivalent called Rust this would be a better world. After all in comparison Rust is safe by nature unlike C or C++. :)
You should not switch your apps. You should stop creating new projects in C++ once Rust is mature enough for your liking.
The fundamental "problem" we're having/facing with C and C++ is the investments we've put in. Lots of "infrastructure" in modern day computing relies on C and C++ and will do so for ages. We can't just drop the projects and switch to something else(say Rust or maybe Go), but we can stop creating new C and C++ codebases to alleviate the problem for the future.
Exactly, it's a chicken and egg problem. C++ has tons of libraries, while Rust has barely any. Rust can use external C bindings, but not C++ ones yet. I think if they solve the issue of using C++ libraries from within Rust, the transition will be much easier, and meanwhile more native Rust libraries will be created.
Yes, in the cases where the operating system is done in C++.
The C ABI is the operating system ABI and it is only ubiquitous in operating systems done in C. Other operating systems use whatever ABI the system offers.
How many Rust libraries are there for various tasks? What IDE supports Rust? What tutorials, books and conferences exist that teach and distribute the state of the art in development techniques? What example projects have been build in it to demonstrate its feasibility for large projects? What tools support Rust (continuous integration, code formatting/checking, build tools, ...)?
Well using make as an example of anything good is... let's say 'suspicious'. There is more to tooling than make and git (note that I deliberately omitted version control from my list)
Not really. The closest is Servo,[1][2] the massively-concurrent browser engine that the language was designed to create. But it's not very featureful yet, and is only a few thousand lines (compared to 100+ kloc for the Rust compiler itself).
It's too early yet to make claims like that. Rust may or may not end up supplanting C++ in some areas, but even in the most optimistic case it definitely won't obviate C++ entirely.
I've been working my way through the Rust tutorial. As much as I like the power and control it gives me, they really need to take a note from Go on the syntax. Some of the even fairly contrived examples are an eye-sore. I need to give it more time but yeesh there's a lot of syntax to look out for.
Not exactly related to syntax, but one of the issues I've found with following the tutorials is that there is only a handful working programs which actually show the feature in question in use. While I understand that (as the tutorial explicitly mentions) the tutorial is very terse and quick glance at the language features, I feel it could be improved tremendously if there was even one a few line fully compilable program exploring the features per section.
Then again I also understand that because the language changes and evolves, maintaining more code in the docs means more effort. However, this is one of the few things I've felt bugging me as an end-user. Of course I believe this can be expected to change for the better in the future as the language matures and stabilizes, but I figured I'd voice this out given this perfect opportunity. :)
That's a good idea, but it's going to require a bit of thought to implement. It might make sense to have an "advanced examples" external page for every section in the tutorial, which would sort of transform the current tutorial into an annotated table of contents. Which could be really neat! But perhaps it should wait until Rust has some analogue to play.golang.org available.
This is not a matter of RAII or "smart" pointers (which are not even smart enough to deal with cyclic references unless the programmer explicitly breaks the cycle). It is a matter of a language whose high-level features are constrained by low-level concerns, where the features compose poorly, and where things that are obvious (like requiring that functions with a non-void return type have a return value along every control path) are simply omitted from the standard. It is dizzying to think of how much money has been spent on bugs that were made possible by C or C++; why are we continuing to waste time and money on these languages?