4 ms·

Is C++ the Language of the Future?

29 points by jemeshsu 15y ago

icefox 15y ago
No
- Smudge 15y ago
  That was my reaction too. I like your brevity.
ootachi 15y ago
No Scala or Rust? Especially Rust seems like it fits the author's wishlist.
demallien 15y ago
Ahhh, He started talking about needing concurrency to be able to make use of multicode CPUs, and his solution is C++ ??? The number of cores is multiplying with Moore's Law. It doesn't take many multiplications before a language able to easily make use of those multicores efficiently will blow past C++ in performance.
- angersock 15y ago
  So, before you rush off to dismiss C++, note a very important thing: With reference-counted smart pointers, you can guarantee that objects immediately go away once they leave scope, and that you can pass them around between threads without worrying too much about a thread forgetting to delete them. No other language has such easy support for doing something like that without relying on a background memory-management mechanism (at least that I'm aware of--I'd like to hear about it if you know one!).
  - mrich 15y ago
    Objective-C with ARC comes pretty close.
    - angersock 15y ago
      Out of curiosity, when does the GC happen there? Does Objective-C have strict enforcement of destruction-on-scope exiting? (not a Objective-C dev, so don't know)
      - ootachi 15y ago
        Yes, Objective-C will reclaim your retained objects promptly (unless you use the deprecated Objective-C garbage collection, which few do and never worked on iOS). The exception is the autorelease pool, which gets dumped at the end of every turn of the event loop. You can promote or demote objects from the autorelease pool at will. Anyway, the biggest problems with Obj-C memory management are (a) you can't allocate objects on the stack, so you're forced into using the autorelease pool for stuff, and (b) you can promote or demote objects from the autorelease pool at will, which means that even the autorelease pool has to malloc, thus you don't get the nice benefits of super-cheap bump allocation that C++ arenas (or a generational GC's nursery) buy you.
        angersock 15y ago
        I'm still a little puzzled by the phrase "promptly"--you mean as soon as it goes out of scope, right? Like, immediately? Anyways, thank you for the information!
        ootachi 15y ago
        Right, as soon as it goes out of scope. (Or when you call release to drop the last reference on it, if you aren't using ARC.)
  - ootachi 15y ago
    Well, you have to make sure that you use atomic reference counting in this case. Using regular reference counting will lead to subtle and hard-to-diagnose bugs. Also, to answer your query, Rust uses unique pointers (the equivalent of std::unique_ptr in C++0x) for inter-thread communication. When the unique pointer goes out of scope, its memory is immediately freed (since it was the only owner of the data). And since the data has only one owner, it's data-race-free.
    - angersock 15y ago
      Yeah, one of the first things we fixed in our smart pointer implementation was to use atomic ops for the ref counters. This had the unfortunate side effect of excluding the smart pointer classes from our STL replacement (as it introduces a dependency on our low-level ops library), but in projects using both all is well. Cool on Rust, though! Thanks for the info!
  - pmjordan 15y ago
    Reference counting is nothing new. Visual Basic used it before the transition to .NET. Python uses it, if I remember correctly (with occasional GC to avoid leaks due to cycles). There are probably countless other examples. Reference counting is also not even that great for shared memory multithreading. The (atomic) increment/decrement operations typically cause lots of cache invalidation, so you'll get a slowdown even for immutable objects.
    - angersock 15y ago
      Ref counting by itself is nothing new, agreed. The fact that I can reliably say when things go out of scope in C++, though, combined with ref counting, is quite handy. Interesting point about the cache invalidation, though. I wonder if we'll see chip vendors going out of their way to improve performance and invalidation when using atomic ops.
      - pmjordan 15y ago
        I wonder if we'll see chip vendors going out of their way to improve performance and invalidation when using atomic ops. They already put a lot of effort into making this stuff as efficient as possible - the fact that Intel is going in the direction of hardware transactional memory indicates to me that they don't think the bus locking/cache snooping approach scales, and I can't say I'm surprised.
    - ootachi 15y ago
      Yeah, atomic RC hurts a lot (5x-10x slower, based on the measurements I've seen -- Hans Boehm of Boehm GC fame did a presentation on this that you can find if you're interested). (This is a problem with Objective-C reference counting -- they use atomic ops for all reference counting I believe.) There's some work on mitigating its cost with per-thread reference counts arranged in a tree or whatever, but it's still tough. The alternatives are either (a) avoiding shared state; (b) strong lifetime management such that you make sure one parent thread owns all of the data that its child threads are going to use; (c) concurrent GC; (d) pretending it's not a problem like Go does and doing stop-the-world GC.
- mrich 15y ago
  Modern C++ code is multithreaded, threading is now finally part of the standard. While C++ is showing its age, and the refusal to cut any old features at all sure is no advantage, it is still the language to beat for performance and especially memory usage.
  - rbanffy 15y ago
    The problem is not the ability to start threads - it's enabling the programmer to express the problems in concurrent form.
espeed 15y ago
Go is a strong candidate because of its concurrency model.
angersock 15y ago
(the inclusion of Ada and the dismissal of go as "not having objects" makes me question the author's wisdom) C++ is likely to be the language of the future, as it is getting to the point where you can pick a subset of the language and emulate your favorite other programming language and paradigms. This is not a good thing.
- wicknicks 15y ago
  Exactly! This has been my concern too. Everybody has their pet subset of the language. With the amount of native features growing with every standard, large C++ codebases look more polyglot than ever.
  - rbanffy 15y ago
    Indeed. There are probably a dozen people in the planet that understand C++ completely. They all maintain compilers.
deleted 15y ago
[deleted]
numeromancer 15y ago
(Note: I define "serious development" as rock solid, enterprise quality software) This guy must be good; I've been looking for the source code for the systems of the U.S.S Enterprise for months now on The Pirate Bay, and still haven't found it. ALSO: I didn't know that this was an Object Oriented world! Ya lern sumthin new evry day. Squirrel!
deleted 15y ago
[deleted]
j_baker 15y ago
I think this post is a non-sequiter. I think the observations the author is making are accurate, but I don't think that any of them but #2 really make a strong case for C++. And even that one is debatable.
lopatin 15y ago
What are the chances a coffeescript-like language for c++ being adopted? I would think that a python like syntax, with utility methods and such, that compiles to c++ would be a huge help if c++ really is going to be adopted more and more in the future.
- phamilton 15y ago
  Why compile to c++? Compiling to javascript makes sense because javascript is the lowest common denominator for browsers. Compiling to c++ wouldn't make any sense when you can compile directly to assembly/bytecode. It would be like writing a python like language that compiled to coffeescript. It would be silly not to compile it directly to javascript.
- qdog 15y ago
  I would think compiling to llvm is probably a better road to go down than compiling to c++, as long as llvm can target the platform you are interested in. C++ could link against your library then. And you could probably do it right now.
- eco 15y ago
  Interestingly, the original C++ compilers were like CoffeeScript in that they'd compile to C source code. Walter Bright (now of D fame) wrote the first C++ compiler that compiled to machine code. I don't really see this as the approach going forward though. There isn't much to gain from compiling to C++ code over C code.
- rbanffy 15y ago
  Why not go the rpython or Cython route? Both have the Python syntax and compile to C. Not very readable C, of course, but not significantly worse than what the first C++ preprocessors did (yes, kids, C++ started its life as a compiler that compiled C++ code into horribly mangled C).
krisc 15y ago
If the JVM persists into the future, I see Clojure as a strong candidate.
qdog 15y ago
No mention of several other languages, like Erlang, which more or less scales up with available hardware threads. However, it doesn't even mention that just having multiple cores on a chip isn't the same thing as having 2 chips, you still have shared memory and the bus, so having 2 cores is not going to be as fast as having 2 chips and 2 sets of memory in most cases, so adding cores is never going to be a linear increase. I believe right now that intel's hyperthreading needs to be turned off for some compile scenarios, as the collisions are too high either for memory or something else (at least 2 people I know who have to do huge compiles disable some of the hyperthreads). In short, I don't believe it's easy to just scale up on multi-core systems, regardless of language. Threads are a pretty dangerous way to do things, processes are much safer, but not all problems fall easily into a parallel model.
aninteger 15y ago
Why would the language of the future be any one specific language? Many languages can make use of multiple cores through threading/open-mp like libraries.
olaf 15y ago
I think, the question is wrong, because of Browsers/Javascript. Not much C++ in sight there, for scripting Browsers/DOM. Even Stroustrup mentioned JS as one of the programming languages programmers should know.
rbanffy 15y ago
> (Note: I define "serious development" as rock solid, enterprise quality software) This guy must be right. I don't see why my opinions should matter because, according to him, I haven't done any rock solid enterprise quality software since 2002 or so. I sure must warn my clients my software isn't up to the current standards of quality, for they rely on my "lesser" solutions. Am I the only one who is sick of this kind of arrogance?
bediger4000 15y ago
First, why C++? Given that you can't truly do threading via a library (http://lambda-the-ultimate.org/node/950 http://lambda-the-ultimate.org/node/950 Lambda-the-ultimate thread for context, and pointers to various versions), it would seem that C++ is not a good choice. Second, why not assembly of some sort, or something very close to assembly? It's hard to break things out into threads and not incur performance problems due to platooning or thundering herds or contention for critical section(s). You want to maximize each individual CPU's work even in a massively multi-processor environment. Assembly gets you performance, guaranteed atomic operations, guaranteed memory barriers. and precise locations of those things. I smell a return to the "semantic gap" and highly orthogonal ISAs.
tomp 15y ago
Whenever I read such an article, I'm amused at how the authors seem to forget that there exist multiple areas of programming: web programming, application programming, industrial programming, real-time programming (finance), ... C/C++ is popular only in the application programming and possibly industrial programming category. I believe that the latter category will become increasingly popular/important in the future (robotics, space travel, even consumer gadgets are becoming "smarter"), and C is a really bad language for any kind of life-critical software, mainly because it cannot be statically analysed (without significantly restricting the language features). Another thing is, in embedded systems, there's much less legacy code, so a new language for that field could very easily win over any existing ones.
- pork 15y ago
  Sorry, which (widely used) language out there can be statically analyzed without restricting language features? And being difficult to statically analyze is hardly a reason to switch to C++.
- rbanffy 15y ago
  I can't see why being able to statically analyze the code brings it any closer to correctness - all it says is that you got your types right. In fact, switching to a lower-level language (as in "more detached from the problem you are trying to solve" such as C or C++) seriously harms your ability to even produce correct code. Anyone who has chased a time-sensitive bug caused by data structures that mutate unexpectedly (be it by conflicting threads, be it by hardware changing it) can tell you that getting the types right won't help you a bit with making code that runs correctly on multi-core machines.
drucken 15y ago
Languages of the future will be written to VMs. The languages on top of the VMs will evolve fast while the VMs become progressively broader in scope. It has already happened for many languages and is already a route companies like Apple have and are investing heavily into, e.g. Clang. Bleeding edge examples include Rust (http://www.rust-lang.org/ http://www.rust-lang.org/) and Clay (http://claylabs.com/clay/ http://claylabs.com/clay/) both on the LLVM.

29 points by jemeshsu 15y ago

icefox 15y ago

Smudge 15y ago
That was my reaction too. I like your brevity.

ootachi 15y ago

No Scala or Rust? Especially Rust seems like it fits the author's wishlist.

demallien 15y ago

Ahhh, He started talking about needing concurrency to be able to make use of multicode CPUs, and his solution is C++ ??? The number of cores is multiplying with Moore's Law. It doesn't take many multiplications before a language able to easily make use of those multicores efficiently will blow past C++ in performance.

angersock 15y ago
So, before you rush off to dismiss C++, note a very important thing: With reference-counted smart pointers, you can guarantee that objects immediately go away once they leave scope, and that you can pass them around between threads without worrying too much about a thread forgetting to delete them. No other language has such easy support for doing something like that without relying on a background memory-management mechanism (at least that I'm aware of--I'd like to hear about it if you know one!).
- mrich 15y ago
  Objective-C with ARC comes pretty close.
  - angersock 15y ago
    Out of curiosity, when does the GC happen there? Does Objective-C have strict enforcement of destruction-on-scope exiting? (not a Objective-C dev, so don't know)
    - ootachi 15y ago
      Yes, Objective-C will reclaim your retained objects promptly (unless you use the deprecated Objective-C garbage collection, which few do and never worked on iOS). The exception is the autorelease pool, which gets dumped at the end of every turn of the event loop. You can promote or demote objects from the autorelease pool at will. Anyway, the biggest problems with Obj-C memory management are (a) you can't allocate objects on the stack, so you're forced into using the autorelease pool for stuff, and (b) you can promote or demote objects from the autorelease pool at will, which means that even the autorelease pool has to malloc, thus you don't get the nice benefits of super-cheap bump allocation that C++ arenas (or a generational GC's nursery) buy you.
      - angersock 15y ago
        I'm still a little puzzled by the phrase "promptly"--you mean as soon as it goes out of scope, right? Like, immediately? Anyways, thank you for the information!
        ootachi 15y ago
        Right, as soon as it goes out of scope. (Or when you call release to drop the last reference on it, if you aren't using ARC.)
- ootachi 15y ago
  Well, you have to make sure that you use atomic reference counting in this case. Using regular reference counting will lead to subtle and hard-to-diagnose bugs. Also, to answer your query, Rust uses unique pointers (the equivalent of std::unique_ptr in C++0x) for inter-thread communication. When the unique pointer goes out of scope, its memory is immediately freed (since it was the only owner of the data). And since the data has only one owner, it's data-race-free.
  - angersock 15y ago
    Yeah, one of the first things we fixed in our smart pointer implementation was to use atomic ops for the ref counters. This had the unfortunate side effect of excluding the smart pointer classes from our STL replacement (as it introduces a dependency on our low-level ops library), but in projects using both all is well. Cool on Rust, though! Thanks for the info!
- pmjordan 15y ago
  Reference counting is nothing new. Visual Basic used it before the transition to .NET. Python uses it, if I remember correctly (with occasional GC to avoid leaks due to cycles). There are probably countless other examples. Reference counting is also not even that great for shared memory multithreading. The (atomic) increment/decrement operations typically cause lots of cache invalidation, so you'll get a slowdown even for immutable objects.
  - angersock 15y ago
    Ref counting by itself is nothing new, agreed. The fact that I can reliably say when things go out of scope in C++, though, combined with ref counting, is quite handy. Interesting point about the cache invalidation, though. I wonder if we'll see chip vendors going out of their way to improve performance and invalidation when using atomic ops.
    - pmjordan 15y ago
      I wonder if we'll see chip vendors going out of their way to improve performance and invalidation when using atomic ops. They already put a lot of effort into making this stuff as efficient as possible - the fact that Intel is going in the direction of hardware transactional memory indicates to me that they don't think the bus locking/cache snooping approach scales, and I can't say I'm surprised.
  - ootachi 15y ago
    Yeah, atomic RC hurts a lot (5x-10x slower, based on the measurements I've seen -- Hans Boehm of Boehm GC fame did a presentation on this that you can find if you're interested). (This is a problem with Objective-C reference counting -- they use atomic ops for all reference counting I believe.) There's some work on mitigating its cost with per-thread reference counts arranged in a tree or whatever, but it's still tough. The alternatives are either (a) avoiding shared state; (b) strong lifetime management such that you make sure one parent thread owns all of the data that its child threads are going to use; (c) concurrent GC; (d) pretending it's not a problem like Go does and doing stop-the-world GC.
mrich 15y ago
Modern C++ code is multithreaded, threading is now finally part of the standard. While C++ is showing its age, and the refusal to cut any old features at all sure is no advantage, it is still the language to beat for performance and especially memory usage.
- rbanffy 15y ago
  The problem is not the ability to start threads - it's enabling the programmer to express the problems in concurrent form.

espeed 15y ago

Go is a strong candidate because of its concurrency model.

angersock 15y ago

(the inclusion of Ada and the dismissal of go as "not having objects" makes me question the author's wisdom) C++ is likely to be the language of the future, as it is getting to the point where you can pick a subset of the language and emulate your favorite other programming language and paradigms. This is not a good thing.

wicknicks 15y ago
Exactly! This has been my concern too. Everybody has their pet subset of the language. With the amount of native features growing with every standard, large C++ codebases look more polyglot than ever.
- rbanffy 15y ago
  Indeed. There are probably a dozen people in the planet that understand C++ completely. They all maintain compilers.

deleted 15y ago

[deleted]

numeromancer 15y ago

(Note: I define "serious development" as rock solid, enterprise quality software) This guy must be good; I've been looking for the source code for the systems of the U.S.S Enterprise for months now on The Pirate Bay, and still haven't found it. ALSO: I didn't know that this was an Object Oriented world! Ya lern sumthin new evry day. Squirrel!

deleted 15y ago

[deleted]

j_baker 15y ago

I think this post is a non-sequiter. I think the observations the author is making are accurate, but I don't think that any of them but #2 really make a strong case for C++. And even that one is debatable.

lopatin 15y ago

What are the chances a coffeescript-like language for c++ being adopted? I would think that a python like syntax, with utility methods and such, that compiles to c++ would be a huge help if c++ really is going to be adopted more and more in the future.

phamilton 15y ago
Why compile to c++? Compiling to javascript makes sense because javascript is the lowest common denominator for browsers. Compiling to c++ wouldn't make any sense when you can compile directly to assembly/bytecode. It would be like writing a python like language that compiled to coffeescript. It would be silly not to compile it directly to javascript.
qdog 15y ago
I would think compiling to llvm is probably a better road to go down than compiling to c++, as long as llvm can target the platform you are interested in. C++ could link against your library then. And you could probably do it right now.
eco 15y ago
Interestingly, the original C++ compilers were like CoffeeScript in that they'd compile to C source code. Walter Bright (now of D fame) wrote the first C++ compiler that compiled to machine code. I don't really see this as the approach going forward though. There isn't much to gain from compiling to C++ code over C code.
rbanffy 15y ago
Why not go the rpython or Cython route? Both have the Python syntax and compile to C. Not very readable C, of course, but not significantly worse than what the first C++ preprocessors did (yes, kids, C++ started its life as a compiler that compiled C++ code into horribly mangled C).

krisc 15y ago

If the JVM persists into the future, I see Clojure as a strong candidate.

qdog 15y ago

No mention of several other languages, like Erlang, which more or less scales up with available hardware threads. However, it doesn't even mention that just having multiple cores on a chip isn't the same thing as having 2 chips, you still have shared memory and the bus, so having 2 cores is not going to be as fast as having 2 chips and 2 sets of memory in most cases, so adding cores is never going to be a linear increase. I believe right now that intel's hyperthreading needs to be turned off for some compile scenarios, as the collisions are too high either for memory or something else (at least 2 people I know who have to do huge compiles disable some of the hyperthreads). In short, I don't believe it's easy to just scale up on multi-core systems, regardless of language. Threads are a pretty dangerous way to do things, processes are much safer, but not all problems fall easily into a parallel model.

aninteger 15y ago

Why would the language of the future be any one specific language? Many languages can make use of multiple cores through threading/open-mp like libraries.

olaf 15y ago

I think, the question is wrong, because of Browsers/Javascript. Not much C++ in sight there, for scripting Browsers/DOM. Even Stroustrup mentioned JS as one of the programming languages programmers should know.

rbanffy 15y ago

> (Note: I define "serious development" as rock solid, enterprise quality software) This guy must be right. I don't see why my opinions should matter because, according to him, I haven't done any rock solid enterprise quality software since 2002 or so. I sure must warn my clients my software isn't up to the current standards of quality, for they rely on my "lesser" solutions. Am I the only one who is sick of this kind of arrogance?

bediger4000 15y ago

First, why C++? Given that you can't truly do threading via a library (http://lambda-the-ultimate.org/node/950 http://lambda-the-ultimate.org/node/950 Lambda-the-ultimate thread for context, and pointers to various versions), it would seem that C++ is not a good choice. Second, why not assembly of some sort, or something very close to assembly? It's hard to break things out into threads and not incur performance problems due to platooning or thundering herds or contention for critical section(s). You want to maximize each individual CPU's work even in a massively multi-processor environment. Assembly gets you performance, guaranteed atomic operations, guaranteed memory barriers. and precise locations of those things. I smell a return to the "semantic gap" and highly orthogonal ISAs.

tomp 15y ago

Whenever I read such an article, I'm amused at how the authors seem to forget that there exist multiple areas of programming: web programming, application programming, industrial programming, real-time programming (finance), ... C/C++ is popular only in the application programming and possibly industrial programming category. I believe that the latter category will become increasingly popular/important in the future (robotics, space travel, even consumer gadgets are becoming "smarter"), and C is a really bad language for any kind of life-critical software, mainly because it cannot be statically analysed (without significantly restricting the language features). Another thing is, in embedded systems, there's much less legacy code, so a new language for that field could very easily win over any existing ones.

pork 15y ago
Sorry, which (widely used) language out there can be statically analyzed without restricting language features? And being difficult to statically analyze is hardly a reason to switch to C++.
rbanffy 15y ago
I can't see why being able to statically analyze the code brings it any closer to correctness - all it says is that you got your types right. In fact, switching to a lower-level language (as in "more detached from the problem you are trying to solve" such as C or C++) seriously harms your ability to even produce correct code. Anyone who has chased a time-sensitive bug caused by data structures that mutate unexpectedly (be it by conflicting threads, be it by hardware changing it) can tell you that getting the types right won't help you a bit with making code that runs correctly on multi-core machines.

drucken 15y ago

Languages of the future will be written to VMs. The languages on top of the VMs will evolve fast while the VMs become progressively broader in scope. It has already happened for many languages and is already a route companies like Apple have and are investing heavily into, e.g. Clang. Bleeding edge examples include Rust (http://www.rust-lang.org/ http://www.rust-lang.org/) and Clay (http://claylabs.com/clay/ http://claylabs.com/clay/) both on the LLVM.