
Is C++ the Language of the Future? - jemeshsu
http://claystuart.blogspot.com/2012/01/language-of-future-is-c.html
======
demallien
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
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!).

~~~
pmjordan
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.

~~~
ootachi
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.

~~~
angersock
Hm... interesting. Looks like we might want to expand our library to have RC
with and without atomic ops--that way we can get some of the cleanness of
scoped destruction when appropriate without having to go whole-hog ATOMIC RC
INVALIDATE ALL THE THINGS when we can getaway with it.

Thanks again folks!

------
bediger4000
First, why C++? Given that you can't truly do threading via a library
(<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.

------
qdog
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.

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

------
espeed
Go is a strong candidate because of its concurrency model.

------
aninteger
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.

------
tomp
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.

~~~
rbanffy
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.

------
lopatin
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
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.

------
angersock
(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
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
Indeed. There are probably a dozen people in the planet that understand C++
completely. They all maintain compilers.

------
j_baker
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.

------
drucken
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/>) and Clay
(<http://claylabs.com/clay/>) both on the LLVM.

------
rbanffy
> (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?

------
numeromancer
_(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!

------
olaf
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.

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

------
icefox
No

~~~
Smudge
That was my reaction too. I like your brevity.

