Channels ▼


The New Native Languages

To many developers, the recent trend of reversion to true compiled languages implies a re-engagement with C and C++, or for denizens of smaller niches, a renewed embrace for Pascal, Fortran, Ada, and other languages of the pre-2000 era. But for some programmers, this native trend, which is most heavily touted by Microsoft as part of its re-engagement for C++, leaves a certain sense of dissatisfaction. C and C++ look a lot like they did in 1995. And even though C11 and C++11 have added useful features that we have been carefully chronicling in Dr. Dobb's, the languages can have the feel of a past era onto which contemporary elements have been grafted.

For developers who yearn for something more modern, languages that reflect current concepts of parallelism, immutability, large libraries, extended data types, and the like there are interesting alternatives; especially since many of them key off the basic C syntax, which makes them comparatively easy to adopt. Chief among these are D (from Digital Mars), Go (from Google), Rust (from Mozilla), and Vala (from Gnome). All four languages are available free and all but D are completely open source. (D is almost completely open source). Looking at these languages provides interesting insights in language design and shows in some ways what C and C++ are lacking. I quickly summarize these four languages in this short slideshow.

All four languages represent simpler approaches to native OO programming than C++. In some ways, this set of language designs underscores a fundamental issue in C++ that the new standard only marginally addresses: an unbridled complexity. More than any other language, C++ lends itself to long explanations of esoteric subtleties and unexpected gotchas hidden away in language features. It's easy, bordering on glib, to say that this is the price you pay for a language that is so powerful, but I don't find that argument convincing. It's the price you pay for the historical habit of glomming on new features that are not tightly managed.

The upshot is that to be truly expert in C++ requires far more education and far more effort than comparable mainstream OO languages (notably, Java and C#). The offsetting problem is that the primary native alternative, C, simply lacks too many features to be used for green-field projects that should not be coded at a low level. The four languages presented here represent interesting options between C's spartan approach and C++'s complexity that offer varying mixes of features and designs. Because I think they should be part of the discussion of the return to native code, we'll explore them in upcoming articles on Dr. Dobb's. Of course, our rich tradition of covering C and C++ will continue unabated. It's just that we'll be adding a few colors to the palate for the time being.

— Andrew Binstock
Editor in Chief
Twitter: platypusguy

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.



I agree! C++ is a jungle of functionalities and arcane gotchas, where you have to know the path to be out of trouble (but on that path it looks fine, just as in the presentation!), but it's easy to tread outside of that path and then you'd better be a survival (C++) expert.


Syntactically C++ is probably only slightly more complex than Java - semantically it is much more complex, with a lot of voodoo behavior that very few actually understand.


I use mainly Java, C++ and Javascript and even together day to day. I also write in C# and shell scripts some tools or helpers when they are more likely to fullfill the task. And from my personal experience, I don't find C++ more complex than Java.

I just feel that in Java and C# writing code is like filling a form : you can't do anything in another way than the language expects it and when writing C++ it's possible to implement a design without any barrier given from the language (e.g. Things like Sister class delegation).

This results in more maintainable code, and I find that it matters because the flexibility being smaller in Java and C#, it's more difficult to change a large application without refactoring the whole.

In fact I find that typing Java code even with all the eclim helps is more difficult and less clear than writing c++ one. I mean if (str.equals(otherStr)) begins already to be unreadable in comparison to if (str == otherStr). And the fact that to copy we have to write a clone() method calling Object.clone with a cast is really a pain in comparison to the default copy constructor provided in c++ which just works.

Additionally in Java I find initializing a list of a map is not that easy in comparison to using boost::assign::list_of, map_list_of or +=.


I think saying that C++ looks like in 1995 is wrong if you don't look at the standard library only. C++03 or C++11 have this flexibility (told as complexity by your article) which library developers can use to bring simplicity and flexibility to library users. You can't say that C++ is like in 1995 if you take a look at boost, because this library provides all the facilities and syntactic sugar to compete with languages like D, Go and so on. It adds features to the language (even new way to express code with Template Meta programming) without the need of an additional compilation step or tool, it simply uses the languages standard features. And nowadays compiler can handle this flexibility without any problem and in a cross platform way (i.e. I'm an embedded developer and I have no difficulties in using C++ for all the platforms I target which starts with MSPs and pass by the ARM families, ending with x86 platforms for linux or windows).

And this is a reason why I think that C++ is not lacking anything in comparison to Go, D and so on, when you use Boost, you will simply write code without having the impression you are lacking anything, you even get the impression that you aren't using all the power you have in the hands.

But I don't criticize the choice to make these articles which will be really interesting, I just wanted to react on the point that I think that objectively we can tell that C++ isn't lacking anything in comparison to the languages you gave and that code written nowadays definitely doesn't looks like code written in 1995.


@VL000 We'll just have to agree to disagree here. The comparison of C++ and Java tends to support my argument. Java has become a complex language. I would disagree with Herb, though, as I think most developers who use both languages would consider C++ the more complex of the two. I cannot comment on C# as I don't know it well enough to put forth a qualified opinion.


"In some ways, this set of language designs underscores a fundamental issue in C++ that the new standard only marginally addresses: an unbridled complexity"
That's just not true. C++ is no more complex than any of its main competitors (java and C#). Herb Sutter stressed this in his presentation at the GoingNative 2012 conference. He compared the size of the language specification documents by word count and found the three to be really close. The difference come mainly from different design philosophies concerning performance/productivity tradeoffs. His talk is very interesting to get an overview of modern c++ and where it is heading; you can watch it here :


There are many libraries and software frameworks available for C++ (Boost, Wt, WxWidgets, etc. etc.) Are any of these languages able to use these, or do they have sufficient support for equivalent functionality?


We really need to get back to native compilation. A lot of processor time is lost in interpreters and JIT engines.

A small correction to your article, D is open source. While the backend of the official DMD compiler is not open source, everything is available at github.

Plus, there are at least the following fully open source compatible compilers:

- GDC (uses the GCC backend)
- LDC (uses the LLVM backend)
- SDC (newly implemented in D)


Maybe it's time for someone to write "C++: The Good Parts", after Douglas Crockford's book on JavaScript. :)>