It's pretty well known that C++ suffers from a variety of problems. Many of them have been known about for some time. Despite this, nobody has been able to produce a truly viable alternative.
There have been some encouraging developments, of course. But they've had their own drawbacks that are often worse, in practice, than the problems of C++.
D is an example of this. A lot of new and existing C++ code probably could be written in D instead. But D lacks the widespread adoption and support that C++ offers. This translates into there being fewer third party libraries available, which increases the burden on programmers to an extent that's usually unjustifiable during commercial development And this, in turn, helps prevent the adoption of D.
Rust is another example. It theoretically sounds like it could be a replacement for C++, but that's only true in the far future. The language and its standard libraries have yet to show any real signs of stability. We've been hearing that there may be a 1.0 release at the end of 2014, but time is quickly running out on this. Even then, it will merely be where D is at that point. While there may be a fair number of Rust libraries in existence at this point, many of them have become broken due to language or standard library changes, many are woefully incomplete, and many are totally abandoned.
Then there are Java, C#, Go and others which claim to be successors or potential replacements, and perhaps this is true in a very limited subset of cases. But the remaining situations where they aren't suitable are large in number and quite critical.
Furthermore, we are continually seeing C++ adapt and evolve. It's getting new features and functionality that these competitors are offering, while still usually giving far more freedom and control to programmers, far better performance, far better portability, far greater practicality, and continued use for serious new software projects. These factors combine to make it an even more difficult situation for potential C++ replacements. They just may not bring enough to the table to warrant replacing C++ for a majority of its users or potential users.
"Then there are Java, C#, Go and others which claim to be successors or potential replacements, and perhaps this is true in a very limited subset of cases." If this sentence was true, we'd see only a small adoption of Java and C#, and huge adoption of C++. But I'm afraid you're wrong, and this is exactly reversed now. There's huge adoption of Java/C# used in critical systems in many big companies, while a few niches like embedded programming, games or HFT still use C++ (not exclusively). This is very, very far from "large in number and critical".
"Furthermore, we are continually seeing C++ adapt and evolve."
Indeed. This C++ job trend illustrates this "growing adoption" very clearly: http://www.indeed.com/jobtrends?q=C%2B%2B&l=
Well, pretty much any time that Java, C# or Go are being used, C and/or C++ are also being used. We can't forget that their major implementations are built with C and/or C++, along with much of the underlying software they run upon or interact with.
I don't dispute that languages like Java, C# and Go being widely used. And while the systems built with them may be critical within a very local scope, such as at the company level, pretty much all software of global importance is still implemented in C, C++, or some mix of the two. This is true almost 20 years after Java came on the scene, almost 15 years after C# did, and almost 5 years Go did.
Go is perhaps the only case where this may change, given how its implementors have expressed interest in porting their existing C code to Go. But that still won't change the fact that the operating systems, databases, and other software systems that Go code often interacts with are still very likely to be implemented using C and/or C++.
Are Wikipedia, Twitter, Facebook, LinkedIn or GMail systems of global importance? If they are not, I'm really curious what is your definition of global importance. Their core functionality has been developed in languages such as Java, Scala, PHP and JavaScript. And when looking at the lowest level, everything runs on OSes written in C (Linux, Solaris), webservers written in C or Java (!), and databases / datawarehouses written in C and Java (!), so even your argument that C++ is being used for all the low-level critical stuff is strongly exaggerated.
Sure, as I said, C++ has some place, but nowhere near being the one and only language to implement such stuff, including database engines, webservers and operating systems.
Well, pretty much any time that Java, C# or Go are being used, C and/or C++ are also being used. We can't forget that their major implementations are built with C and/or C++, along with much of the underlying software they run upon or interact with.
I don't agree. If someone is programming in Python, they are programming in Python. They aren't programming in C, in addition to Python, just because the VM or whatever is programmed in C. If some language displaces C or C++ in some niche, then it has displaced it, even if the VM of the implementation of the language happens to be written in C or C++. The important distinction, I think, is what people are programming in.
This is like saying that "nothing has proven to be viable alternatives to cement for building houses" when talking about building entire houses with cement, if the foundation of houses are always made up of cement. The fact that the rest of the house can be built with other materials like wood or bricks is a crucial point, in that context.
You realize your criticism of D has nothing to do with the language itself, and everything to do with network effects, and first-to-market effect? Of course D lacks the widespread adoptions of C++, it's a newer language! The same goes for your criticism of Rust.
If I were moved by these objections, I would conclude that we shouldn't even try to overthrow established programming languages. Heck why not embrace Status-quo Bias altogether?
About Java & co, you need to realized that most C++ code out there didn't need C++ (or D, or Rust) in the first place. The projects that are (i) very demanding to the CPU and memory, (ii) need a complex solution, and (iii) can't possibly separate a few bottlenecks in C from a high level language with a good FFI (Python, OCaml, Lua, Haskell, Lisp…), are uncommon. Some of those projects have incredible impact, but they are still uncommon.
Java & co are for projects where it was a mistake to use C++ in the first place. They don't compete with C++ on its own turf, they just take away territory C++ should never have controlled.
No, D's lack of adoption does involve the language itself to some degree. While the core language itself is better than C++ in some ways, these benefits just aren't compelling enough to exceed the downsides of D, nor do they outweigh the benefits that C++ offers.
And D isn't a new language, by any means. It has been out there for well over a decade now. That should be more than enough time for it to achieve relatively widespread usage, were it to actually offer sufficient benefit over C++ and its other competitors.
I don't know D, so I wouldn't know about it's downsides, besides the one you have spoken of already: lack of adoption. What are the downsides of D that wouldn't go away if it was widely adopted?
You say D is sufficiently old, that it's lack of adoption is significant evidence that we should never adopt it. The problem is, most people think like you do: they wouldn't adopt a language before it has some visible traction. The corollary is, new languages never get widely adopted, unless of course some Big Corporation does massive publicity around it (Java, C#…). The real reason D isn't widely adopted, is not because it's not better than C++. It's because it was not widely adopted in the first place. Textbook chicken and egg.
You speak of benefits and downsides of a language, but what you are really speaking of is the whole ecosystem as it is now. You don't even look at the long term potential.
Also, put yourself in the shoes of a language designer. Say you have a brilliant programming language. Experimental quantitative research has shown with no ambiguity that your language is better than some established, old language in its own niche (20% more productivity, 10% less post-release bugs, same observed runtime speed and memory consumption…). Just one little problem: your language have zero users, and only a little standard library. How would you get people to adopt your new language?
Hint: people won't believe your peer-reviewed experiments. People will refuse to learn a new syntax. People will want to reuse their old code. Even if you come up with an automatic translation tool, people will not trust it. People will say the benefits of the language are outmatched by the drawbacks of its standard library (too small), and of its community (none to speak of). People will be afraid of the required training (even if your research shows productivity benefits after a couple weeks).
How do you fight Status-quo Bias?
Personally, I found only one answer, which unfortunately isn't applicable everywhere: making the new language's implementation so cheap that all it's costs are paid off in a single project. DSLs may do that: with the right tools, a small external DSL can take no more than a couple hundred lines to implement.
You realize your criticism of D has nothing to do with the language itself, and everything to do with network effects, and first-to-market effect? Of course D lacks the widespread adoptions of C++, it's a newer language! The same goes for your criticism of Rust.
Yeah, it's basically a catch-22: lang X is not a viable substitute because it isn't mature enough/not mature enough ecosystem, and continually and relentlessly stating and reinforcing this point will just keep discouraging people from adopting (and indirectly improving) these languages, since clearly... there haven't been any languages that have been able to displace C/++, so what's the point.
And, according to Pacabel, even if you manage to break through some niche with these languages, most underlying software (OSs, VMs, etc.) will still be written in C/++. So if you reimplement the whole bottom of the stack with other systems languages, only then can you talk about displacement, apparently. A tall order.
I have an easy counter to Pacabel's argument: Apple used to use PowerPC. Now they're on X86. People used to use 16bits, then 32bits CPUs. Now they use 64bits CPUs. Operating systems have followed, and soon, programs will as well.
My point is, if you can abstract the underlying architecture, you can replace it. It's difficult because most complex abstractions leak, but it has been done in the past. That Javascript virtual machine written in C++ could be re-written in Rust.
So, even if displacement means "you are not even allowed to use C/C++ as a target language", and "you are not even allowed to use OS services written in C/C++", we can still "displace" C and C++. It won't happen any time soon however. I believe we need to wait for something like mainstream FPGAs.
The problem with current processors and C/C++ is, they tend to be optimized for each other. If instead we had something like an FPGA running at desktop speed, programs would be compiled to logic gates instead of being compiled to assembly. This would dig a grave for C++.
Comments
It's pretty well known that C++ suffers from a variety of problems. Many of them have been known about for some time. Despite this, nobody has been able to produce a truly viable alternative.
There have been some encouraging developments, of course. But they've had their own drawbacks that are often worse, in practice, than the problems of C++.
D is an example of this. A lot of new and existing C++ code probably could be written in D instead. But D lacks the widespread adoption and support that C++ offers. This translates into there being fewer third party libraries available, which increases the burden on programmers to an extent that's usually unjustifiable during commercial development And this, in turn, helps prevent the adoption of D.
Rust is another example. It theoretically sounds like it could be a replacement for C++, but that's only true in the far future. The language and its standard libraries have yet to show any real signs of stability. We've been hearing that there may be a 1.0 release at the end of 2014, but time is quickly running out on this. Even then, it will merely be where D is at that point. While there may be a fair number of Rust libraries in existence at this point, many of them have become broken due to language or standard library changes, many are woefully incomplete, and many are totally abandoned.
Then there are Java, C#, Go and others which claim to be successors or potential replacements, and perhaps this is true in a very limited subset of cases. But the remaining situations where they aren't suitable are large in number and quite critical.
Furthermore, we are continually seeing C++ adapt and evolve. It's getting new features and functionality that these competitors are offering, while still usually giving far more freedom and control to programmers, far better performance, far better portability, far greater practicality, and continued use for serious new software projects. These factors combine to make it an even more difficult situation for potential C++ replacements. They just may not bring enough to the table to warrant replacing C++ for a majority of its users or potential users.
"Then there are Java, C#, Go and others which claim to be successors or potential replacements, and perhaps this is true in a very limited subset of cases." If this sentence was true, we'd see only a small adoption of Java and C#, and huge adoption of C++. But I'm afraid you're wrong, and this is exactly reversed now. There's huge adoption of Java/C# used in critical systems in many big companies, while a few niches like embedded programming, games or HFT still use C++ (not exclusively). This is very, very far from "large in number and critical".
"Furthermore, we are continually seeing C++ adapt and evolve." Indeed. This C++ job trend illustrates this "growing adoption" very clearly: http://www.indeed.com/jobtrends?q=C%2B%2B&l=
Well, pretty much any time that Java, C# or Go are being used, C and/or C++ are also being used. We can't forget that their major implementations are built with C and/or C++, along with much of the underlying software they run upon or interact with.
I don't dispute that languages like Java, C# and Go being widely used. And while the systems built with them may be critical within a very local scope, such as at the company level, pretty much all software of global importance is still implemented in C, C++, or some mix of the two. This is true almost 20 years after Java came on the scene, almost 15 years after C# did, and almost 5 years Go did.
Go is perhaps the only case where this may change, given how its implementors have expressed interest in porting their existing C code to Go. But that still won't change the fact that the operating systems, databases, and other software systems that Go code often interacts with are still very likely to be implemented using C and/or C++.
Are Wikipedia, Twitter, Facebook, LinkedIn or GMail systems of global importance? If they are not, I'm really curious what is your definition of global importance. Their core functionality has been developed in languages such as Java, Scala, PHP and JavaScript. And when looking at the lowest level, everything runs on OSes written in C (Linux, Solaris), webservers written in C or Java (!), and databases / datawarehouses written in C and Java (!), so even your argument that C++ is being used for all the low-level critical stuff is strongly exaggerated.
Sure, as I said, C++ has some place, but nowhere near being the one and only language to implement such stuff, including database engines, webservers and operating systems.
I don't agree. If someone is programming in Python, they are programming in Python. They aren't programming in C, in addition to Python, just because the VM or whatever is programmed in C. If some language displaces C or C++ in some niche, then it has displaced it, even if the VM of the implementation of the language happens to be written in C or C++. The important distinction, I think, is what people are programming in.
This is like saying that "nothing has proven to be viable alternatives to cement for building houses" when talking about building entire houses with cement, if the foundation of houses are always made up of cement. The fact that the rest of the house can be built with other materials like wood or bricks is a crucial point, in that context.
You realize your criticism of D has nothing to do with the language itself, and everything to do with network effects, and first-to-market effect? Of course D lacks the widespread adoptions of C++, it's a newer language! The same goes for your criticism of Rust.
If I were moved by these objections, I would conclude that we shouldn't even try to overthrow established programming languages. Heck why not embrace Status-quo Bias altogether?
About Java & co, you need to realized that most C++ code out there didn't need C++ (or D, or Rust) in the first place. The projects that are (i) very demanding to the CPU and memory, (ii) need a complex solution, and (iii) can't possibly separate a few bottlenecks in C from a high level language with a good FFI (Python, OCaml, Lua, Haskell, Lisp…), are uncommon. Some of those projects have incredible impact, but they are still uncommon.
Java & co are for projects where it was a mistake to use C++ in the first place. They don't compete with C++ on its own turf, they just take away territory C++ should never have controlled.
No, D's lack of adoption does involve the language itself to some degree. While the core language itself is better than C++ in some ways, these benefits just aren't compelling enough to exceed the downsides of D, nor do they outweigh the benefits that C++ offers.
And D isn't a new language, by any means. It has been out there for well over a decade now. That should be more than enough time for it to achieve relatively widespread usage, were it to actually offer sufficient benefit over C++ and its other competitors.
I don't know D, so I wouldn't know about it's downsides, besides the one you have spoken of already: lack of adoption. What are the downsides of D that wouldn't go away if it was widely adopted?
You say D is sufficiently old, that it's lack of adoption is significant evidence that we should never adopt it. The problem is, most people think like you do: they wouldn't adopt a language before it has some visible traction. The corollary is, new languages never get widely adopted, unless of course some Big Corporation does massive publicity around it (Java, C#…). The real reason D isn't widely adopted, is not because it's not better than C++. It's because it was not widely adopted in the first place. Textbook chicken and egg.
You speak of benefits and downsides of a language, but what you are really speaking of is the whole ecosystem as it is now. You don't even look at the long term potential.
Also, put yourself in the shoes of a language designer. Say you have a brilliant programming language. Experimental quantitative research has shown with no ambiguity that your language is better than some established, old language in its own niche (20% more productivity, 10% less post-release bugs, same observed runtime speed and memory consumption…). Just one little problem: your language have zero users, and only a little standard library. How would you get people to adopt your new language?
Hint: people won't believe your peer-reviewed experiments. People will refuse to learn a new syntax. People will want to reuse their old code. Even if you come up with an automatic translation tool, people will not trust it. People will say the benefits of the language are outmatched by the drawbacks of its standard library (too small), and of its community (none to speak of). People will be afraid of the required training (even if your research shows productivity benefits after a couple weeks).
How do you fight Status-quo Bias?
Personally, I found only one answer, which unfortunately isn't applicable everywhere: making the new language's implementation so cheap that all it's costs are paid off in a single project. DSLs may do that: with the right tools, a small external DSL can take no more than a couple hundred lines to implement.
Yeah, it's basically a catch-22: lang X is not a viable substitute because it isn't mature enough/not mature enough ecosystem, and continually and relentlessly stating and reinforcing this point will just keep discouraging people from adopting (and indirectly improving) these languages, since clearly... there haven't been any languages that have been able to displace C/++, so what's the point.
And, according to Pacabel, even if you manage to break through some niche with these languages, most underlying software (OSs, VMs, etc.) will still be written in C/++. So if you reimplement the whole bottom of the stack with other systems languages, only then can you talk about displacement, apparently. A tall order.
I have an easy counter to Pacabel's argument: Apple used to use PowerPC. Now they're on X86. People used to use 16bits, then 32bits CPUs. Now they use 64bits CPUs. Operating systems have followed, and soon, programs will as well.
My point is, if you can abstract the underlying architecture, you can replace it. It's difficult because most complex abstractions leak, but it has been done in the past. That Javascript virtual machine written in C++ could be re-written in Rust.
So, even if displacement means "you are not even allowed to use C/C++ as a target language", and "you are not even allowed to use OS services written in C/C++", we can still "displace" C and C++. It won't happen any time soon however. I believe we need to wait for something like mainstream FPGAs.
The problem with current processors and C/C++ is, they tend to be optimized for each other. If instead we had something like an FPGA running at desktop speed, programs would be compiled to logic gates instead of being compiled to assembly. This would dig a grave for C++.