
C++11 Makes Competitors Go Rusty - NerdsCentral
http://nerds-central.blogspot.com/2012/02/c11-makes-competitors-go-rusty.html
======
jerf
Your freaking enormous ball of mud accreted some more mud. _Quelle surprise_.
It's probably doing it by sheer gravitational attraction at this point. I do
not think that removes the need for languages that have the capabilities of
C++, yet aren't freaking enormous balls of mud.

The reader may mentally replace my use of the word "freaking" with other
choice terms at his or her discretion.

~~~
javadyan
Any useful language is a freaking enormous ball of mud. Bjarne said: there are
only two kinds of languages - the ones people complain about and the ones
nobody uses.

~~~
jerf
I can not think of a cognitively bigger language than C++. And I mean
_language_ , not library set or anything like that, but literally, what the
syntactic constructs are, how they are defined, and in particular how they end
up interacting with each other. I often wonder how many of the C++ defenders
could actually answer detailed questions about it, or how much of the code
they write would actually deeply, deeply surprise them with what memory
allocation bugs are lurking, how much indirection there really is, or how many
implicit copies of things they are making if they really took the time to step
through the assembly language version. Or how many of them could bang out a
decently accurate _summary_ of the new official memory model, let alone how it
might interact with all of the other features of C++. Or for real bonus
points, successfully use it without introducing enormous numbers of things
that are, technically, errors, but it so happens you never run into them at
runtime.

Non-zero, I'm sure, but I bet single-digit percentages, tops. Except that last
one, which I'd put money on sub-1%.

What are the odds that C++, as a fairly extreme outlier, is actually closer to
optimal for the general purpose tasks it is used for than all the other
languages?

~~~
javadyan
You can replace C++ with almost any other mainstream language in the above
paragraph and it would still hold true. Problem is, contemporary general-
purpose languages are used for such a wide range of different tasks that it is
simply impossible for them not to be complex (syntactically or in terms of
runtime envoronment). And yes you can hide complexity behind abstractions
(which our programming languages successfully do), but you cannot really
eliminate it. And despite all that I see more real-world applications written
in "horrible" languages like C++ or Java than in "elegant" languages like
Common Lisp.

~~~
jerf
I can write Java code that will not surprise me with unexpected copies,
contain huge memory problems (GC does have edge cases, but if you throw that
in I will throw in "non-trivial memory management in C++ when 'just use a
smart pointer' doesn't work" and you don't come out ahead at all), or surprise
me greatly with the memory model. It doesn't have a huge syntax, and the
language doesn't get 50% bigger on every release of the syntax. Many Java
programmers can answer questions that go quite deep into how Java works.

I don't like or use Java, and it isn't perfect by any means. My point is just
how far I _didn't_ have to go down the list of "mainstream languages" before
your claim is completely false. C++ is an _outlier_.

C also has the memory leaking issue, but the rest is false as well. Though in
the memory model case it's by virtue of not having one.

And that's sticking with a very generous-for-you interpretation of
"mainstream". If I'm allowed to dip down to Python or something you're even
worse off.

~~~
javadyan
All I can say is, I can write C++ code that will not surprise me with
unexpected copies, contain huge memory problems, or surprise me greatly with
the memory model.Stop whining and learn to use your tools, goddamit.

------
strlen
I (shrug) enjoy programming in C++11 and like many concepts in it.

However, there are concepts in Go and Rust that are salient and stand on their
own: typeclasses in Go and Rust (concepts, unfortunately, were left out of
C++11), rust making std::unique_ptr<> a language feature and support for
pattern matching, etc...

While I like support for atomics, memory model, etc.. in C++11, concurrency is
still a library in C++. Go and Rust take different approaches to concurrency,
but they do make it a _language_ feature which is substantially different.

In short, I hate to bible-thump Paul Graham's article, but this article does
remind me of the "blub paradox".

tl;dr I like C++11, but I am glad there are other options (most importantly,
Go, and Rust) being developed for userland systems programming.

~~~
Arelius
I'd like to note that rust does allow mutable shared state, but just in an
"unsafe" context, since it is in fact, unsafe.

~~~
ootachi
Rust has typeclasses as well.

~~~
strlen
Edited appropriately. Please excuse my ignorance, then. I've only recent began
looking at Rust, but I've been playing with Go for some time now. Will have to
spend more time with Rust (if only there were more than 24 hours in a day...)

------
angersock
So, just to fan the flames a bit...

About half of his points are general gripes about software development,
regardless of language(s): license infections, learning new languages, writing
languages with the wrong idioms, runtime versioning issues, wah wah wah this
all reads like somebody throwing up arguments just to try and distract
readers.

His complaint (read:strawman) about interoperability and performance is really
misleading. His 'Compatibility' section is not unfair, _but all of those
problems are faced by programmers dealing with system libraries anyways_. Tell
me more about the C++ bindings to C libraries and how they are never used in
production.

His complaint about 'Performance' is similar FUD. Jesus, dude--if you agree on
a calling convention, I can probably get my Brainfuck program to compile and
interop with your C library. The computer really doesn't give two shits what
language caused the stack pointer to move--it doesn't matter. This isn't a
valid complaint.

His lambda is dumb. He didn't do anything there that couldn't have been done
with a function pointer, C-style. If he was trying to show why C++11 lambdas
are cool, he failed.

(and his code looked like garbage, as others here have mentioned... elegant my
ass. No comments, ugly use of operators, namespacing--beautiful C++ this
ain't.)

EDIT: Found this, same author I think ( [http://nerds-
central.blogspot.com/2012/01/sql-failed-experim...](http://nerds-
central.blogspot.com/2012/01/sql-failed-experiment.html) ). SQL is a
distraction--quick, somebody warn Oracle that they'll be out of business!

Maybe the poor person is just getting lonely in that ivory tower?

------
mrj
Ironically his code sample makes me think we need a new language right away.

------
megaman821
Of course C++ can do what Go and Rust do, C++ can do everything, but that is
the problem with it. C++ tries to do everything and it leaves it not being
very good at nearly anything. Also, C++ code-bases are all using different
subsets of functionality. It makes becoming a product commiter to a code-base
to longer than it should.

------
ComputerGuru
A couple of nitpicks:

 _C++/Tr1 has also solved many of the same problems without needing a new
compiler_

Not true. While many of the boost/tr1/c++0x features are introduced via new
headers, there are many compiler-level changes, and that's why you need to use
the latest versions of clang/g++/msvc/icc to take advantage of them. Things
like r-value references just can't be done without a "new" compiler.

My other nitpick is his code sample: I've been write C++ for _years_ but I
must say his code sample made my eyes bleed. It's rather far from being
demonstrative proof that C++ is elegant and need not be replaced. He should
have just imported all the namespaces and been done with it, for starters, in
this trivial sample.

~~~
CJefferson
I wonder if you are confusing TR1 (which came out several years ago), and
C++11.

TR1 was designed to not need compiler extensions (although some parts of
type_traits, that AFAIK no-one ever used in the TR1 days, could be improved
with compiler support). TR1 added regex and tuple among others. It certainly
didn't have rvalue references.

C++11 is the new big standard, which certainly requires large amounts of
compiler support.

~~~
ComputerGuru
No, but I suspect the author of TFA is/has. That would explain the
inconsistencies throughout his post.

------
scott_s
I like and use C++. It fits my requirements of allowing high performance but
still having rich abstractions. I also like most of the additions in C++11,
and I look forward to using them.

But, there is a valid argument for using a newer language that has nothing to
do with the language itself: the ancient include, compile and link process.
Having to do the #ifndef/#define/#endif dance in every header file I write is
a reminder of this fact. That hack exists because 40 years ago, there was no
concept of package management. I feel the same way when I get linker errors
that require me to unmangle my class names to figure out what's visible where.

~~~
munificent
> Having to do the #ifndef/#define/#endif dance in every header file I write

I'm just using "#pragma once" in my current hobby C++ project. I understand
pragmas are living in sin, but is there any reason I shouldn't use them?

~~~
rbrown46
#pragma once aside, I agree that not having to worry about writing and
including headers _at all_ is a significant improvement of Go over C++.

------
slavak
I find the concept of a C++ programmer using the ABI as a bullet-point
_against_ switching to a different language highly ironic.

------
shenberg
_Compatibility: The new language will have to talk with older languages. Types
will have to be translated; memory models will need to be aligned and
compilers will need to 'play nice' together. This is not just as the compiled
object level but at the ABI level during linking etc._ I've spent more time
solving issues with memory models in C++ than I have in any other language
because C++ has no ABI - I've had patches to MSVC change the memory layout of
objects and cause breakage which is just as bad as you get with any sort of
language interop scenario.

 _Performance: This new language is super fast. Great, but it will have to
work with existing systems. The interface between the two will slow stuff down
a lot..._ Seeing as C++ has no ABI, there's no non-hacky way to provide a C++
binary shared library that doesn't end up using a very small subset of C++
(for example, no STL, since it's all templated, meaning the code your compiler
generates won't interoperate with the code the client's compiler), which means
people end up wrapping their C++ code with C APIs.

 _Build: ..._ #include is a broken piece of legacy that everyone will be happy
to see disappear - give us real modules instead of a compilation model which
pastes file contents inside other files. Also, C++ compile times are
ridiculously long compared to a modern CFG-based language (that's disregarding
the fact that compilers often disagree as to what's valid code because of the
extremely complicated syntax of the language).

 _Debugging: ..._ Debugging modern code that uses shared_ptr, bind, etc. is
such a massive pain in the ass because you end up mixing the code you care
about with those plumbing details - "step into " becomes useless. Add the fact
that there is no ABI and you find yourself unable to introspect objects at
runtime when compiled in release mode (where all the nasty memory issues tend
to show up)

 _Team Training: ..._ C++ is, as I've been ranting, complicated. I've been
using it for a long time, and there's still no language in which I fear making
subtle mistakes that'll cause hard-to-diagnose bugs (for example, exceptions
are often treated as an anti-pattern because it's so hard not to make such
mistakes using them)

 _Team Embedded Knowledge: ..._ This is a valid point. I don't think it's
worth the price you pay for using C++...

 _[Ecosystem complaints - tooling, licensing, lifespan]_ Beyond the fact that
tooling for managed languages is often superior to C++ (because of the better-
controlled memory layout and execution model), these are valid points.

 _Startup And Shut-down Sub-Systems: ..._ This is also broken in C++ - in what
order are static objects initialized (definition order inside a cpp file, file
sequences are random)? What happens if one wants to refer to another? I know
these are solvable issues, but every single one of them requires thought and
effort on the programmer's side, and these aren't the sort of issues that a
programmer should be wasting his time on.

 _Paradigm Contamination: ..._ Yes, writing in a language and writing
idiomatically in a language are two different things, but modern, idiomatic
C++ is both something I've seen few people who know (compared to out-dated and
dangerous practices), and it still requires more effort to keep in mind than,
say, writing idiomatic python, or C#, or java.

 _Brain Strain (the bilingual problem): ..._ This isn't really an argument -
it's speculation. I could say that perhaps the fact that C++ is so varied that
different subsets of it end up looking like different languages, and all of
them with more details you have to keep in mind to make sure you aren't
breaking stuff subtly. Also, being bilingual also provides cognitive
advantages, so even that flawed analogy might not be proving the point.

 _Let us think about the big ideas behind Go: [snip] Well, one can write
simple clean C++ and use share_ptr. Just because C++ can be super complex does
not mean it has to be._ Unless, say, you're writing a DLL (another fun fact:
not only can your API not have STL, exceptions also can't cross DLL
boundaries), or you're using DLLs written by other poor souls who were
consigned to writing DLLs with a C++ API.

This is not to say that C++ has no place in software development (I use it
daily at work), but I'm of the opinion that unless you have a really good
reason, avoid it like the plague. New languages taking over more niches C++
used to occupy is a good trend.

As a finishing note, one of my favorite articles on the subject of complexity
in programming: <http://www.joelonsoftware.com/items/2009/09/23.html>

~~~
to3m
I'd like to upvote twice, but it wouldn't let me.

So it's cruel, but I usually secretly assume that people who keenly advocate
C++ are just poseurs.

Anybody who has actually gone through the whole process of making a program in
C++ and fixing enough of the bugs in it that somebody can put it in a box and
sell it in the shops, is appropriately circumspect in their recommendations,
because they know just how appallingly awful it can get.

So awful, that you'd give up on exceptions, DLLs, new & delete, templates,
STL, auto-registering static globals, and all that kind of stuff - because
it's actually EASIER to give up all those time-saving modern conveniences,
than it is to pick up the pieces after they've been overused.

But nobody believes it until it's happened to them. It just sounds too
implausible...

~~~
cpeterso
Amen! There are good reasons why Google's [1] and Mozilla's [2] C++ style
guides frown on C++ features like exceptions, RTTI, iostreams, and static
objects.

I read an anecdote that Bill Joy has a "copy of Bjarne Stroustrup's _The C++
Programming Language_ in which he's highlighted all the sections that Java
programmers don't need to concern themselves with." I wonder what a
C++-compatible subset language would look like if someone just deleted code
from a C++ grammar. Rather than writing style guides and lint scripts, just
whittle down a C++ compiler's front-end. :)

[1] [https://google-
styleguide.googlecode.com/svn/trunk/cppguide....](https://google-
styleguide.googlecode.com/svn/trunk/cppguide.xml)

[2]
[https://developer.mozilla.org/index.php?title=en/C%2B%2B_Por...](https://developer.mozilla.org/index.php?title=en/C%2B%2B_Portability_Guide)

------
jchonphoenix
Sure C++ can do what Go and Rust do. In fact any language that is turing
complete can do anything that any other turing complete language can do. It
just matters how easy to do it and how the syntax is. It's all about warts,
and C++ has a lot of them.

~~~
Symmetry
Is it just me, or could the author know only Go and Rust from their Wikipedia
entries?

~~~
enneff
It's not just you. This made me laugh: "Let us think about the big ideas
behind Go: It is simple, clean and has garbage collection." Enough said,
really!

------
0x0
_Let us think about the big ideas behind Go: It is simple, clean and has
garbage collection._

That's quite a bit of an oversimplification. Goroutines and channels are two
big ideas in Go, and the author pretty much ignored those completely.

------
ori_b
As soon as he said _"both Google and Mozilla have been playing the 'new object
oriented native language' game recently"_ , I stopped reading.

If you aren't sufficiently familiar with either language to know that neither
of them is particularly object oriented, at least in the traditional sense,
then you probably shouldn't be writing about them.

~~~
pmr_
I agree that this paragraph is badly worded but the rest of the article hardly
deals with anything related. There are some valid issues here that have
nothing to do with the programming paradigm advocated and supported by either
language.

------
mrich
C++ is great if used with care, the problem is that it has too many features
and many things are quite braindead. Features are hardly ever removed (I like
the Python approach better) But for complex, high performance applications it
is still the best choice.

------
SamReidHughes
How many people here who complain about the language being too complicated
have actually been _harmed_ by the presence of features in the language? If
you want an advanced programming language, it's going to be complicated.
Without garbage collection, it will be even more complicated. Almost every
feature that exists in C++ exists for a reason, and every one that was added
or removed in C++11 was added or removed for good reasons.

If you want a less complicated language than C++11, other than some low-
hanging white noise inherited from C, you'll probably have to give up safety,
convenience, performance, or exceptions.

~~~
drivebyacct2
No offense, but have you spent much time with Go or Rust? In most cases Go's
performance difference isn't extremely divergent from C++'s and it preserves
safety and enhances convenience, exceptions and adds concurrency.

~~~
cageface
Last I heard the Go compiler was generating code 6x or more slower than
comparable C++ code. Is that not still true?

~~~
enneff
You heard wrong: <http://blog.golang.org/2011/06/profiling-go-programs.html>

~~~
andrewcooke
The graphviz / svg output from the profiler shown there is very nice. Does
something similar exist for other languages? I particularly like the scaling
of the node size by the appropriate value (CPU time, memory use, etc).

~~~
enneff
Go's pprof is based on the C-based one: <http://code.google.com/p/gperftools/>

------
16s
I do systems programming and I use C++ a lot. It's perfect for that. Anyone
who does systems or embedded stuff will tell you how wonderful C++ is over the
alternatives.

------
Mavrik
I hate to be "that guy", but for someones sake, fix the site on ipads. Not
only it tells you you're using an incompatibble browser (a blast from IE
past), then it swirtches to iPad specific (????) non-zoomable fixed layout,
which makes it pain to read.

Really, how can a tech person think this is a good idea of publishing content?
Please fix it.

------
akkartik
It all boils down to whether you're starting a new project/binary. If you are,
go with the new and leave all the backwards-compatible crap behind. If you
aren't, then this article will speak to you. I also wouldn't want to be in
your shoes.

------
drivebyacct2
I have fun when I write code with Go. I love the syntax, type inference and
standard libraries. I wrote a transcoding video http server with html frontend
in like a hundred lines of code and it doesn't make my eyes bleed. I don't
think Go needs to replace C++ but I certainly _prefer_ it. I think there are
tons of uses for C++ still obviously (least of which is Go's GC-nature), but I
don't think C++11 makes redundant the space that Go can occupy.

I know it's personal preference (but frankly, so is the article's position)
but that C++11 code looks terrifying to me, I'm still guessing at what several
of the pieces of code do. A python programmer looked at my go-code and very
easily deduced what it was doing and made good suggestions immediately.

edit: s/VM/GC

~~~
4ad
Just a small nit, Go does not use a VM. It's compiled to machine code.

~~~
drivebyacct2
You're absolutely right, I thought GC and wrote VM.

