Is C++ the Language of the Future?

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.

First, why C++? Given that you can't truly do threading via a library (<a href="http://lambda-the-ultimate.org/node/950" rel="nofollow">http://lambda-the-ultimate.org/node/950</a> Lambda-the-ultimate thread for context, and pointers to various versions), it would seem that C++ is not a good choice.<p>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.<p>I smell a return to the "semantic gap" and highly orthogonal ISAs.

No mention of several other languages, like Erlang, which more or less scales up with available hardware threads.<p>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).<p>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.

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

Go is a strong candidate because of its concurrency model.

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.

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), ...<p>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.

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.

(the inclusion of Ada and the dismissal of go as "not having objects" makes me question the author's wisdom)<p>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.<p>This is not a good thing.

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.

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

&#62; (Note: I define "serious development" as rock solid, enterprise quality software)<p>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.<p>Am I the only one who is sick of this kind of arrogance?

<i>(Note: I define "serious development" as rock solid, enterprise quality software)</i><p>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.<p>ALSO: I didn't know that this was an Object Oriented world! Ya lern sumthin new evry day.<p>Squirrel!

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.

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

No