C++, it’s time to go

I’ve been studying a lot of languages lately, looking for a modern, parallel language which is a deserving successor to C/C++/Python as my main, go-to language for Getting Things Done.  Someone on Reddit was specifically asking why C++ isn’t ideal any more, and I wrote up this response based on my research.  So, I thought I’d repost it here, too.

Let’s get right into what’s wrong with C++, then, and why I’d sooner replace it.

a) OO with class hierarchies is a broken model. Traits/interfaces with UFCS (aka extension methods), or even just structures with plain old functions and namespaces, is a MUCH better, more flexible approach that leads to better, more maintainable code.  You only have to consider that, traditionally, a method is a function which REQUIRES a class within a hierarchy as the first argument, to realise that this is true. There’s a reason why modern languages (D, Rust, etc.) are doing this, rather than following C++’s model.  Dijkstra said:

Object-oriented programming is an exceptionally bad idea which could only have originated in California.

Lately, I think he was right all along.  But even out of those old-style OO approaches Dijkstra was talking about, C++ implemented it poorly, with diamond inheritance issues, virtual inheritance vs. normal inheritance issues, lack of an override keyword until recently, etc.

b) Algebraic datatypes and pattern matching have been around for years, and have clear advantages, both in terms of expressive power, and code reliability. If your language doesn’t support them, it sucks.  For anyone unfamiliar, ADTs with pattern matching are like tagged unions and a switch statement to check the values in C++.  Except, where the compiler can only check that all cases are matched in C/C++, ADT-supporting languages can unpack data structures, check the fields inside, and check that you’ve handled each case, without leaving something out — even across recursive functions.  They’re called algebraic types because the language understands the rules behind the types.

c) Parallel programming has been around for years, and is becoming CRITICAL for modern applications. If your language doesn’t EASILY support it, it sucks. For example, dealing with threading and locking and worrying about safely sharing data between threads is EXTREMELY low-level, compared to other languages. A number of languages now will manage multiple OS threads for you, multiplex many green threads on top, manage a very small per-thread stack by default and grow it as necessary, manage communication between threads, etc., all with convenient, built-in syntax. Some languages will also do parallel loops with virtually no extra syntax, let you throw in closures, etc., while allowing that thread-based communication system to work with it. Some languages even check protocols between threads at compile time, making sure your threads don’t get out of sync or access pointers they shouldn’t access.

d) C++ has a RIDICULOUS amount of boiler plate. Compare Scala’s syntax for creating a class ctor, or Python’s syntax for it. Compare the inheritance of methods in python with C++ (constructors, for instance). Compare the deriving keyword in Haskell / the derive keyword in Rust. Compare the AST macros of languages like D, Rust, and Nimrod with C++’s macros and templates. C++ is LESS POWERFUL, LESS EXPRESSIVE, and WASTES YOUR TIME.

e) Headers shouldn’t exist in the language: modules should. The C++ committee acknowledges this, but won’t be getting it done until C++14, at least.  Headers exist for a reason, but a modern language would work around these, handling definition loops and providing blackbox API definitions in other ways.

f) The same problems that make highly-parallel code (relative to other languages) a nightmare in C++ also make it an unsuitable language for security-critical, or mission-critical projects. There are just too many opportunities to introduce bugs which could allow someone to compromise the software (and then the server, and then the network, and then customer’s systems/services), and too many opportunities for bugs that could bring down a system in PRODUCTION. By contrast, languages like haskell and rust check your code MUCH more thoroughly at compile-time.  Languages like D provide good support for design by contract, so you can catch your program at the function boundaries, if it ever behaves incorrectly.

C++ is loved for expressiveness, high-performance, flexibility, and strong type checking. Of those four, MANY languages do two (expressiveness and type-checking) MUCH better: D, Rust, go, etc.) A smaller, but still significant number of languages do those two better, AND compete strongly or even out-compete C++ on the other two. As languages, with real code, written idiomatically, Rust, D, and others will blow C++ out of the water, if you bear in mind that being able to easily write fast code matters, that being able to easily write parallel code matters, and that a LOT of time has been put into optimising C++ compilers, which is not indicative of the language, but the focus of those involved with it. By now, anyone sane should be looking elsewhere for future planning, even if they find themselves still using C++ for legacy reasons.


  • C++, it’s time to go http://t.co/jeHcApTu8e

  • Nice post! As a python programmer I have much appreciation for the effort that goes into a language and it’s readability, expressiveness and overall usefulness. Python still fits that bill for me but I suspect implementations like PyPy are going to be an interesting leap forward for dynamic languages.

    I keep an eye out for new languages such as Go, Rust, Io, etc; but honestly there is something to be said about the idiomatic nature and clarity of Python.

    Nice article :)

  • Lee wrote:

    Python is great. It’s a very flexible, intuitive language. With PyPy, it’s even rivalling C for speed (but not memory overhead, sadly). PyPy just implemented Python 3 as well, which is a great boost. If it was more of a high-performance systems language, without the GIL, I’d love it. If it’s meeting your needs right now, I’d definitely say stick with it :)

    The main limit I run into with Python is that, for the kind of work I do, it just doesn’t perform well enough. I tend to pump many gigabytes of data through my code on a daily basis, breaking that data down, building it up into higher-level data, and doing analysis. For that kind of stuff, you really need parallelism, without a GIL, and preferably a lot of help to make sure your parallel code is correct.

    That brings me to the other issue: type-checking: Python’s flexibility is great, but sometimes it’s TOO flexible. Once your code base hits a certain size, you tend to want the language’s help to confirm that everything is interfacing correctly. Type-checking, design by contract, etc., are all good ways to do that, but are a bit lacking in Python. You can bolt things on, and in SOME ways, that’s ideal: code quickly, then add stability where you need it. But sometimes it’s hard to retrofit strictness into existing code, and all that extra stuff would add more performance issues, too.

    In short, type-checking really needs to be IN the language, but with a lot of help from the language to avoid endless type declarations. Most modern languages are doing this by making you specify the types in function signatures (mostly sensible, for reliable ABIs), but not requiring type definitions within a function, if it can be inferred from the signatures of other functions or literals used. Languages like haskell take this much further, though, doing whole-program type inference, then just having an FFI (foreign function interface) for ABI compatibility.

  • RT @planetpython: Lee Braiden: C++, it’s time to go http://t.co/3g1V6aFcTz

  • RT @p1xelcoder: C++, it’s time to go http://t.co/rvGmGYAzHD

  • Nice concise article.

    What is your opinion on C? To me, it plays a vital role to implement either
    high-performance data processing or low-level, hardware communication and still
    beats C++ in terms of interoperability due to its simpler ABI.

  • Lee wrote:

    I *really* like C. It’s the language I learned first (apart from a bit of dabbling in BASIC), from K&R’s C Programming Language book. Especially learning it from there, C has always struck me as a very elegant, minimalist language, with few limitations — for its time and target audience, that is. It still has a lot of C++’s flaws, but it doesn’t claim to be the modern, A-grade language any more, so I’m more forgiving of it, within its niche.

    I agree that C’s simpler ABI is a big plus point. It’s also just more flexible: you CAN still write OO code, if you don’t mind SEEING pointers to functions in your structs, or prefixing functions with the type name they apply to, for instance, but you don’t lose flexibility in the process, because a certain STYLE of OO isn’t forced upon you, and it will just be C to the a linker, either way.

    I only mentioned C++’s inelegance above in passing, but the contrast with C is why I mentioned it: C++ just doesn’t have this kind of elegance, to my mind; it’s more of a poorly-integrated mash-up of different ideas.

    In many ways, I’m looking at some other languages like D as more of a spiritual successor to C than C++ is. When coding in D, for instance, I feel much more like I’m doing “modern” C, than I do when coding in C++.

    As many people say, it’s easy to look at C and get a very good idea of what the machine code will look like, which is a big plus. And with the lack of alternatives, it’s easy to understand why C is still popular. I do think it lacks in safety and parallelism, though, and it looks like Rust may well finally be a good successor, as soon as it hits 1.0.

    The sad thing is that D probably could have been that successor too, if they hadn’t dropped the ball too many times, on licenssing, language maturity, release processes, etc. I suspect Rust will be worth waiting for, though.

  • Lee Braiden: C++, it’s time to go http://t.co/Nzv1AQBwpX

  • yolo wrote:

    have you checked out mythryl?


    sml/nj with posix legs and a c-face.

  • asd wrote:

    Isn’t Python created by c++?

  • Lee wrote:

    Python is written in C, rather than C++. But it doesn’t really matter: that’s an implementation detail. In theory, any turing-complete language can implement the core of python (maybe not the GUI, hardware libraries, etc.).

    Anything classed as a “systems language” should be capable of implementing python as-is, libraries and all.

    Also, note that python HAS been implemented on the Java platform, on the dot-net CLR, etc. I believe that PyPy, the other really interesting implementation of Python besides the default one, implements Python on top of RPython, which itself is on top of C (not C++) and LLVM.

  • Paul Perkins wrote:

    Right except for one interesting point: RPython is not exactly on top of C. The RPython language is implemented by a compiler that is written in Python! The RPython compiler breaks the loop so that pypy isn’t an infinite regression of interpreters interpreting interpreters.

  • C++, it’s time to go http://t.co/NWwaZhInyy #scala

  • RT @p1xelcoder: C++, it’s time to go http://t.co/rvGmGYAzHD

  • Vasileios Anagnostopoulos wrote:

    I agree with you on all points.
    However many languages like Rust/Python and others are written in C++. Moreover gcc now and llvm are being written in C++. What happens when C++ vanishes? I personally believe that there is not an obvious answer. But if C++ goes one needs a replacement which should be written in Asm/C. ocaml has started as an alternative to writing compilers and guess what it is written in C. In this respect I feel we need a better C standard to write base compilers and possibly ocaml or haskell to write the more complex compilers. Or even gnu-smalltalk. So I agree to you and since D has a c-only implementation I would argue in re-writting gcc in D or Rust while having a small C compiler as a bootstrap. PCC or even tinyCore C are not that bad. C++ should totally go.

  • Lee wrote:

    I believe Python is implemented in C, rather than C++. LLVM is C++, though, yes.

    We do rely on both these languages, at present, and there is a bootstrapping issue. Most languages bootstrap themselves after a while, though, progressing more and more to self-bootstrapping, with a minimal amount of C (as opposed to C++) or assembly to really get the ball rolling. Rust and D both support inline assembly, and many languages are C-ABI compatible, allowing assembly to bootstrap them. So, there would be no reason that C/C++ should hang around forever in Rust, D, or even other languages that can use a languages like those for bootstrapping, rather than using C/C++. It’s already easy to find operating systems that are written in Rust with just a bit of assembly to get them started, for instance. There are even OSes written in Haskell, though I’m not sure what they use to bootstrap: possibly something fun, like Harpy.

    All that said, I don’t believe C++ will ever fully disappear, just as COBOL hasn’t yet disappeared. Also, I don’t really care if a C/C++ compiler is installed and used to bootstrap a more sensible language. But when people have meetings discussing languages for a new project, I think C++ should just excuse itself from the room, to avoid embarassment ;)

  • Barn wrote:

    The Rust compiler is written in Rust, not in C++. Even the language’s runtime is written in Rust. The only bits of C++ that exist in the compiler are for interoperation with C++ libraries (such as libuv).

  • Dinh wrote:

    FYI: Rust compiler is written in Rust

  • C++, it’s time to go http://t.co/RLKQtzt2HW

  • C++, it’s time to go http://t.co/nqAilYWhOz

  • RT @rickasaurus: Some hard truths in there though RT @ashalynd Yay flamebait! — C ++, it’s time to go http://t.co/Pof4xoHgBc

  • I use C++ for scientific programming using well-established platforms (CGAL, BOINC) that aren’t available/efficient in languages like Python, Ruby, F#, or Clojure.

  • Lee wrote:

    I’m not saying you should abandon legacy code or port it all, just that you shouldn’t CHOOSE C++ when evaluating modern languages on their merits as languages.

    That said though, most compiled languages like D, Rust, Haskell, etc. can bind to C, and C++ if the library was made with ANY sort of cross-language portability in mind. If it wasn’t, there are STILL some options, like SWIG, but really, you can’t blame other languages if you choose tools that are so incompatible.

    That said, there ARE actually python bindings for the two frameworks you mentioned:


    There are also similar frameworks for some languages (python actually has a very well established scientific computing community), if you’re willing to consider porting to similar libraries. Again though, I don’t think you should, for this kind of scenario. COBOL is still in use, and justifiably so. It’s just that it’s not sensible to use it for the VAST majority of modern tasks.

  • Fustbariclation wrote:

    Why no mention of Ada? It’s modular, handles parallelism well, is now available free and is reliable.

    It also, interestingly, runs faster than assembly language.

  • Lee wrote:

    It’s a fair question. It’s a capable language, in later versions at least. To be honest, I’d rule it out very early, on basic requirements of “style”. I rank Ada somewhere around COBOL in terms of “syntax modernity” (understandable, since it’s about as old as C). I also feel like, being around so long, it’s had its chance to become a big player. So, between the two, I don’t think many people will ever adopt it. It also lacks a few things which are beginning to prove necessary, like (some version of) functional paradigms.

    On being “faster than assembly”: this is not possible, assuming the assembly is optimised correctly. Assembly is just machine code in readable form, and everything eventually becomes machine code. It may well be that an Ada compiler can do better than hand-optimised assembly, but many compilers do, these days, given architecture complexities, variations between processors, etc.

    Most of the points you raise are good, though: Ada is sophisticated, in terms of most of the features I’ve discussed in the main post. I particularly like the range checking on integers, which is rare in other languages without throwing in asserts everywhere.

  • Giovanni Rosotti wrote:

    There are some good points in this post, although I find it quite biased to be honest. It’s clear that the author doesn’t like C++, but he is not really fair anymore, particularly in the point of multi threading. The recent additions to C++11 are not even mentioned; plus, there are excellent open source, portable libraries available (such as Intel TBB).
    I kind of agree with the points after that, although one should point out that very widely used languages (e.g. Java, C#) suffer from the same problems.
    I declare my ignorance for the problems with OO and algebraic patterns. It would be good if the author could add some references for the claims he makes. And again, with some minor variations the C++ OO model is the same of all mainstream languages (java, C#), so if the author’s arguments are that strong one should basically discard most of the code that is being written nowadays.
    Finally, while I’m also very interested in languages like Go, Rust and D, one should at least mention that their small user base (up to now, at least) makes it difficult to use them in real world projects, due to the lack of existing code, online resources and available libraries. This point matters when deciding which language to use in a new project, probably even more than the features of a language. Therefore, while I found this post interesting and provoking, I can’t agree with the conclusion that C++ hasn’t a place anymore for new projects.

  • Lee wrote:

    On small user bases… there are certainly other considerations, besides the language itself. How many programmers you can find that know your new language is also a valid question. However, for the purposes of this post, I feel libraries and existing developer experience aren’t huge factors, as I’m mostly talking about new languages, and the best choice of languages for new projects. Clearly, those languages are going to have a hill to climb, but so did C, and C++ at one time. C++ had the benefit of running (most) existing C code, but really, that’s not an issue either: most languages (compiled or otherwise) will bind with C libs in some way, and for any reasonably large project, the chances are that choosing a better language and generating some bindings will at least get you equal development / maintenance time to sticking with an older, uglier language.

    On bias: I’m definitely biased. As Oscar Wilde said:

    One can only give an unbiased opinion about things that do not interest one, which is no doubt the reason an unbiased opinion is always valueless.

    I’ve spent a lot of time, and invested a lot of effort in C++, that could’ve been time better spent, with other languages. It’s time I can’t get back. It’s flexibility I can’t get back. Its code elegance that I can’t get back. Do I want to keep doing that? Do I want others to keep doing that, when there are better alternatives? Absolutely not.

    However, I assume your real point is that I didn’t back up every statement with cold hard facts. That much is true, but then, that isn’t my goal with a short post on a forum, which was then re-posted to my blog. There are plenty of critiques available on C++ itself, if you google for them, and a few have said it better than I could. My main point here is not to point out C++’s flaws (which I think most people are aware of), but to point out that there are actual, pratical solutions available, in the form of better languages; that C++ really isn’t the one true systems/professional language that many professional developers think it is.

  • Jeff Morgan wrote:

    The thing is–and I own Anthony William’s newest book on the C++11 threading library–the additions are hard to keep track of and aren’t as easy to express as in other languages.

    In go, I can express threading ideas that used to seem really complicated to me: http://play.golang.org/p/Y3I7c8TB6S

    Even with the new c++ contructs–namely futures, lambdas, and the new thread object–I can’t express this as cleanly or clearly. The reason for this is that C++ has too many artifacts of it’s ancient history.

    I shouldn’t have to worry about the memory of an object when I throw it into a thread (most of the time–and when I do I should then opt in to be able to manage that memory). I should have to worry about pointers, references, R-value references (or other things that I can std::move)… it just clutters what I’m trying to accomplish, more often than not.

    Furthermore, I shouldn’t have to struggle with a lot of the issues C++ has that doesn’t give any benefits, ever. References and memory managed can be excused because it can be argued that there are many benefits to having that level of access… But the c++ include system and inheritance rules? Not to mention the shear size of the language spec… C++ isn’t suited for large projects anymore… it’s too hard to reason about and maintain. (I work for a company that a products shipping with millions of lines of C/C++ code…).

    Go, for instance, has built in profiling, testing, and package management tools. It’s hard to go back to a language like C++ after using a language that was actually designed for modern problems (like threading and maintaining large code bases.

  • Javi wrote:

    Nice article. After more than 20 years programming in C++, in my opinion, C++ has an incredible burden of trash, D is what C++ should be, the only thing that I hate about D is the garbage colector… I think it was a very bad idea to include a GC in a system programming language like D.

  • Lee wrote:

    Worth noting that, like python, D has a gc.disable() function, as well as gc.collect() for very manual control:


    For instance, I’m sure you could disable garbage collection during a game level, and collect at level cleanup, if you wrote your code in a RAII style (which is appopriate for D anyway). That’s probably very similar to what you’d do manually. You can also just override malloc() and free() in D for different allocation techniques. That’s not the same as manually controlling the garbage collection, but it’s also a useful option. For example, allocating a large block of memory from the OS once, and just incrementing counters on allocations, is much faster than asking the OS for memory regularly.

    See also, the realtime and Smooth Operation sections, here:


    Also, this discussion is quite interesting — a developer starts off asking why his rendering code is slower than C++, saying that he’s already disabled garbage collection. After a few small optimisations / workarounds, the code then performs faster than C++.


    Finally, it is possible to override the garbage collection functions, and get a backtrace if they’re ever called (or perhaps just when a backtrace flag is enabled, for instance, if you can manage the linking of two identically named functions — I suspect there’s a way to do that by separate linking steps).

    All that said, I agree that D should have optional garbage collection. Rust is doing that, for instance.

  • Javi wrote:

    Sure, it’s posible to disable the GC but only temporary, keep in mind that the D standard library uses it so you must live with it… : (

  • eris0xff wrote:

    Excellent summary of the C++ issues. C, D and Lua programmer here. I do network and systems programming and really welcome the commercial adaption of D, especially wrt Facebook and Andrei. I also welcome the fluid ways that algorithms can be expressed. Haven’t seen that kind of tight notation since Pascal/Modula. Finally feel good about the foundations of my Lua/D concurrent programming system.

  • sacado wrote:

    I do not really agree on what you wrote here. There are niches where C++ is still (and will remain for quite a time) the only possible choice, on par with C (which has issues regarding type safety and productivity, even compared to C++).

    One key domain is, despite what you say, safety-critical systems. In this field (in particular, avionics), the use of pointers, recursion or dynamic memory allocation is strictly forbidden (for provability issues). Here, anything where you don’t have a total control of your memory layout is out. Haskell ? It’s probably the worse option in this domain, despite your claims. D ? Why not, but it does not have a proven track record in anything critical, and leaving the GC out seems rather hard. Rust ? Possible, but we will have to wait it exists before we can tell for sure. Until that, I have to drive my car, medical devices have to keep people alive, nuclear plants have to keep cooling, etc.

  • Lee wrote:

    There is nothing INHERENTLY unsafe about recursion or dynamic memory allocation. Recursion is nothing but a function call with a risk of stack overflow — when used erroneously, or not properly checked. Dynamic memory allocation is nothing more than manipulating lists of space, with a risk of doing it wrong. In both cases, unsafe IMPLEMENTATIONS are the real problem, and it’s thanks to languages like C and C++ that they are unsafe.

    As for Avionics, the other BIG competer in that space is Ada, which was specifically designed for the job of being a military-grade language to replace the many unreliable languages around, such as C. Ada 2012, in particular, has advanced features like conracts that make it a much better choice than C/C++. If you don’t feel like Ada is a modern language, there is also real-time Java (admittedly, not DO-178B approved), Aeonix’s PERC Ultra VM (used in missile defence systems), etc. Also, JSR-302, and as you say, Rust are coming soon.

    As for proven track records… that helps, but really, anything this critical should be rigorously tested for bugs: combinatorially testing the software (so that the implementation is tested fully, regardless of language used), extensively testing components, finished products, etc. It’s just that writing in a safer language will very likely create less of those bugs. Implementation issues and unfound bugs aside, if used well, D would be a safer LANGUAGE for this than C++ (it has Safe-D, and Ada 2012-like DBC, for a start).

  • Németh Péter wrote:

    I have a proposal for extending the C++ language with some of these https://github.com/hun-nemethpeter/cpp-reflector-mini/blob/master/Proposal.md

  • C++ is time to go… http://t.co/6RTb8r0L5h – Do you agree @dcsobral ?

  • C++, it’s time to go http://t.co/piQ00nOZJU

  • raphael wrote:

    I agree with many things here but one comment shocked me!


    how can you say that PyPy can match c speed ? this is non sense !

    A poorly implemented c/C++ program can be beaten by a JIT compiler. But how can you expect this:

    –> use a C coded JIT to compile/interpet an instruction sequence
    –> execute the instruction sequence

    to run faster than:

    –> the instruction sequence itself

    I’ve always wonder how people can even say that a JIT compiler for language X generate faster code than the compiled language Y.

    unless the compiler and/or the program implementation is crap, A compiled language should always ultimately outperform a JIT/ virtual machine/ interpreter /….

    100% machined code generated, “Compiled language” will always be necessary for some purposes:

    –> performance ( Ex: in automatic trading, one order goes through and makes money, all other fails ) C+inline ASM
    –> In what language do you write your JIT, interpreter, and virtal machines ?
    –> do you want your OS to run on top of a JIT ?

    I agree though that

  • Lee wrote:

    You should read a little more into how JITs really work. Often, they’ll precompile entire blocks of code, and run them many times, for instance. Yes, there’s a startup/new-processing-phase delay in that, but just as much as you’d think, relative to the total execution time of many programs. It matters a lot for shell scripts, but not so much for serious number crunching, for example.

  • Craig wrote:

    A poorly implemented c/C++ program can be beaten by a JIT compiler. But how can you expect this:

    –> use a C coded JIT to compile/interpet an instruction sequence
    –> execute the instruction sequence

    to run faster than:

    –> the instruction sequence itself

    The answer to that is simple: make JIT compilation take on the order of microseconds/milliseconds (a.k.a negligible overhead) and then allow a form a dynamic profiling (tracing) to guide the optimization and specialization of the machine code in ways that are inconvenient or impossible for AOT compilers. LuaJIT does both of these and actually *does* beat C in some benchmarks. Now you can say what you want about benchmarking, but no other dynamic language (and even most static languages) can’t even fake that kind of performance, let alone consistently.

    tl;dr Not every JIT compiler is Java.

    On the subject of PyPy: it’s authors have already come out and said that it’ll never rival LuaJIT in performance and the approach they’ve taken is one of “decent performance improvements, for a reasonable amount of effort”. You could also phrase that as “Python is a horrible and difficult-to-optimize language — let’s not disappoint ourselves by trying to compete with serious, well-designed languages/compilers.”

  • Danny wrote:

    I’m a long term C/C++ developer.

    I LOVE C for it’s minimalism but it’s just not relevant for real (desktop) development anymore.

    I know C++ very well at this point and I’m pretty fed up with it. It’s stuck in the 90s and I see developers making the same mistakes over and over again because the language encourages abuse.

    It’s also too dependent on the quality of the compiler vendors. C++11 support is being hampered by Microsoft for example.

    I’m very interested in Google Go but there will be no challenger to C/C++ until there is significant third party support – compilers and IDEs, GUI libraries like Qt etc.

    Some form of interop layer is also required to interact it the OS C or Objective-C interfaces.

    Overall it’s a bleak picture. I would love to throw away C++ but I don’t see it happening.

  • Scott R. wrote:

    I LOVE C for it’s minimalism but it’s just not relevant for real (desktop) development anymore.

    It’s the “desktop” that’s barely relevant “anymore”[sic]. C is more relevant than ever, for implementing fast library code that can be called from almost any language.

    Most new languages are sacrificing some speed for safety, and are including full C interop, while only having partial or no C++ interop. That makes C a very attractive option for writing performance critical code that the host language can’t quite match or writing portable libraries once that can be called from many other languages. Not to mention it’s usefulness as the ABI of interpreters and bootstrapping language of compilers.

    C++ is useful for nothing, because it’s awful and deeply flawed as a standalone language and implementing interop for other languages is not worth the enormous effort required. When idiots claim that “C++ is as portable as C”, they always miss the point about interop, which requires an unreasonable amount of work. C wins by virtue of being tiny and *much* more portable in practice.

  • Interesting read: “C++, it’s time to go” http://t.co/7DCYBjaE5l

  • German Diago wrote:

    “C++ is useful for nothing, because it’s awful and deeply flawed as a standalone language and implementing interop for other languages is not worth the enormous effort required.”

    Well, I would say that for being so useless, there are too many people and industries using it.

    I have been using it since 2002 until today and I can’t say I regret my investment, just the opposite. About portability: C is a bit more portable and doesn’t have the name mangling problem. But for the rest, I think C++ is a better alternative for writing APIs. You can always expose an “extern C” interface.

  • RT @matraty: Interesting read: “C++, it’s time to go” http://t.co/7DCYBjaE5l

  • Erik Alapää wrote:

    The simple fact is that if you want the speed of C (and faster than C in many cases) and the abstractions of fluffier languages, C++ is often the most practical language for demanding applications. It IS a complex language that requires reading and a LOT of experience to excel at, but once you are there, it is a fantastic tool, despite its imperfections.

    /Erik Alapää

  • Lee wrote:

    I half-agree with you, Erik. Setting aside the (common, and commonly incorrect) assumption that people who dislike C++ don’t know it as well as those who like it… Yes, C++ is fast, and yes, and sometimes you have to sacrifice to get that speed :)

    However, this is not my point. The same things can be said of C, and I like that language much more. The problem with C++ isn’t complexity (it’s not really THAT complex), but unwieldiness and inelegance.

    Compare Rust, for example, which provides a superset of C++’s features, is potentially faster because it’s higher-level (and so the compiler can understand and optimise more), is safer, AND is more elegant. That language is not ready for prime-time yet, admittedly, but it’s a great example of how other options can genuinely be better, if you’re willing to evaluate each language fairly.

    In the meantime, you have Go [better for most use general apps, including “serious apps” like Photoshop], Ada [better for mission-critical apps], D [mostly a superset of C++, and well worth considering] and others.

    Like you say, C++ has imperfections, and the others all do as well, but lately, C++ has very little going for it that isn’t done better elsewhere.

  • Chris wrote:

    There a few things I find very weird about your posts ;).

    1) How can you like C and dislike C++? Yes, C is not a perfect subset of C++, but it mostly is one. So that argument is rather esoteric. The reason some people seem to prefer C over C++ is because “bad programmers write bad code in C but horrible code in C++”. So for the best of it, chosing C over C++ simply is a matter of “team spirit”. Sacrifing the major leap forward you would naturally get with “C++ done right” for the sake of not having to deal with horrible C++ code produced by the (probably overwhelming number of) bad programmers in the team.

    2) The reason C++ is still used is not because of Legacy code. It’s not because of performance or portability or skillsets. It is because there are NO alternatives. I am learning RUST atm and I have learned a bit D too a few years ago. Yes, those languages seem awesome. But as long as they don’t have the big players (Google, Microsoft, Intel, Apple, etc.) REALLY behind them to create the IDEs & tooling as well as a JRE or .NET comparable class library around them, they are only one thing: A nice toy to play with and dream about a how the world could be IF ONLY ;)…

    That’s pretty much it. As long as RUST/D are not fully picked up and supported by the major compiler vendors, no one will use them in production.

    Further, with the appeareance of Clang and the ability to safely refactor and scan hundred million of lines of C++ code at once, pretty error reporting and code style checking, there isn’t really much point in switching to RUST/D. The effort is far too big. I am saying that the days of C++ are numbered, but I am certain that there will be no shift away from it the next 5 years at least. There are just no viable alternatives.

    If you can use Java & .NET… or JavaScript if you are in web development (I heard some fancy folks even use it for desktop apps, save me pls). Go for it! But for certain kinds of projects, and this includes MANY real-life applications, C++ is THE ONLY choice, even if you would start from scratch again.

    Most of the flaws you mentioned have to do with “normal C++” anyway. C++ can be written in a way that doesn’t have most fo the issues you mentioned. But it requires discipline, knowledge and very good programming skills. I think by now you can tell, why most C++ projects are a big pile of pigshit :D.

  • Lee wrote:

    Chris, to answer your points:

    1) I prefer C to C++ in the same way that I prefer a classy car to “The Homer”. Nothing esoteric about that. I feel all good developers have an appreciation for elegance, just as mathematicians do.

    2) It’s painting MUCH too broad a stroke, to claim that there are no alternatives to C++. And that is really the point of my article, which you’ve missed. Not for ALL use-cases, but for many use cases, there ARE alternatives. Often, they are better alternatives, as already discussed. The argument that a language cannot be successful until it has many libraries is one I sympathise with, but ultimately, find to be self-fulfilling. Every language starts in that position, and good languages overcome it when people see the advantages of writing the necessary infrastructure in those languages, rather than sticking with the status quo. So, that’s a moot point.

  • Chris wrote:

    Someone else mentioned that “C++ will always be there because LLVM & stuff is written in it”. That is just completely wrong.

    Any language that would even attempt to supercede C++, say D & RUST, will be able to compile operating systems from scratch. Any language that even can attempt to overthrow C++ from the system level programming throne, MUST support OS & Compiler & VM development in its full and complete nature. C++ will be in a museum in about 20-30 years and people will look at it and say “Those were the days, my son!”…

  • Frank wrote:

    I like this article. I consider myself something of a language nerd. Fortunately or unfortunately I got started doing embedded during the heyday of K&R C. I have followed c++ through all the twists and turns and am now in the process of learning c++11. But I keep wondering if another language can supplant c/C++ to become the “Lingua Franca” of computer programming. I think one of the underweighted aspects keeping c/c++ in business is it’s utility as a systems language. You need something to bring your system up in the first place so as a rule the first compiler on any new system is always a C/c++ gompiler usually gcc/g++ these daya. Can any of these languages D/Rust do embedded tasks like boot an O/S or be the source language for a compiler? The funnny thing is when I think about it there’s no reason it has to be C so it’s more of a dogmatic tradition then a real technical hurdle, still I’ve never heard of anyone writing bootstrap code in “D”.

  • Lee wrote:

    Bootstrapping is tricky, yes. Most languages rely on some sort of established runtime, and so need to be bootstrapped themselves, and so, are unable to run on bare metal. That’s true of every language in a way though, as they all tend to have a complex standard library, not all of which is available in embedded / bootstrapping code. The main question is whether they can be sanely trimmed to support the creation of bare metal code. Go and D would probably have difficulty with this, but even in .NET, it’s possible. Rust, particularly, seems to be excelling at competing with C/C++ in this domain: it’s not even at version 1.0 yet, and already, there are a few OS kernels written in it, along with ports to phones, etc.

Leave a Reply

Your email is never shared.Required fields are marked *