26 ms·

Why I don't spend time with Modern C++ anymore

276 points by nkurz 10y ago

fsloth 10y ago
This sounds like it's written from the point of view of implementing something inhouse. I fail to see how FPGA programming will be relevant if one wants to distribute software for consumers (or am I technologically clueless...).
- ishi 10y ago
  According to the writer's LinkedIn profile, he comes from the world of High Frequency Trading. That's an area where performance is so important, that it might make sense to design your own hardware. And you certainly don't want to distribute it to anyone... I do agree with the writer that with each release, C++ has become more and more complicated, seriously hurting the maintainability of C++ code.
  - entelechy 10y ago
    I also agree that c++ is getting more and more complex over time. However if you build things from scratch and you cherry pick your language features, C++ can be quite pleasant.
    - TheOtherHobbes 10y ago
      That's the problem - C++ isn't one language, it's at least three generations of languages living together in the same compiler, like an extended family crammed into a tiny apartment. No one has moved out since 1983, and new additions just keep on coming.
      - gpderetta 10y ago
        We c++ programmers are very welcoming. We have yet to meet a paradigm that we didn't like. On a more serious note, any old system acquires cruft with time and you don't always have the luxury of throwing away pieces or even restarting from scratch.
    - ishi 10y ago
      It may be pleasant for you, but not so pleasant for the next developer who needs to maintain your code. Perhaps he likes picking different cherries than yours...
  - daemin 10y ago
    So it seems like he wants people to learn FPGA based programming languages (Verilog, VHDL) because he will need to hire (more of?) these people soon.
- easytiger 10y ago
  Sounds like he is suffering from bias of the problem domain he is working on right now.
  - asveikau 10y ago
    Which, to be fair, is also an apt description of defenders of C and C++ (I consider myself in that category). We are all susceptible to the biases of niches we have worked in and what we have seen working well in those niches. C and C++ can be made to shine in some ways that I get the strong impression many people who happen to not have the same experiences will never appreciate, and perhaps that's not even a bad thing, maybe that just is.
  - adrianratnapala 10y ago
    But that problem domain is dominated by the need for speed -- which is exactly where C and C++ are supposed to have a competitive advantage.
hellofunk 10y ago
This article is not very general. Much of what it tries to convince us is not going to matter for most developers, and has the cost of suggesting modern features are not good for any developers. For example: >It is not rare to see Modern C++ applications taking 10 minutes to compile. With traditional C++, this number is counted in low seconds for a simple change. This is simply a bogus statement with respect to what at least 90% of c++ developers do on a daily basis. I have benchmarked unique_ptr, auto, brace initialization, lambdas, range-based-for and other modern idioms and found them all to be at least as fast, and often faster, than their older counterparts. Now, if I were to instead go off and write template-heavy code using new features, that would be different. But in reality, the vast majority of c++ developers -- I'd wager at least 95% -- are not writing variadic templates on a daily basis (nor should they be). The memory safety and many benefits from unique_ptr [0] is one of many modern tools that is a non-brainer to use in nearly all contexts. No, not nearly all contexts, allow me to rephrase: all contexts. It just is, and if you compare its use to manual new/delete code, the benefits are solid and faster. The author further claims that modern C++ is less maintainable and more complex. The absolute opposite is true in nearly all cases. Using unique_ptr again as an example, it leads to less code, less complex code, more clear code, and better maintainability and code readability. Uniform brace initialization is another example that prevents many common older problems in the language. FYI the author keeps talking about high frequency trading as an example of why modern c++ is a bad choice. Well, I worked at a HFT firm for a long time until last year, the firm places millions of trades per day and is among the most successful in the markets it trades. And what did we use? Only modern features. Lambdas, auto, unique_ptr, range-fors, even std::async -- everywhere in our code. This author is either naive or political. I think the title of this article is highly misleading, and the contents are not relevant. Overall, this article is just bad advice for most of us. [0] https://news.ycombinator.com/item?id=11699954 https://news.ycombinator.com/item?id=11699954
- daemin 10y ago
  I got the feeling that the author's beef with Modern C++ is the same as for any C++ that is template heavy. And to me it is not a new or unique experience (i.e. not limited to Modern C++) to have builds that take 45 minutes to build everything. It can happen in older code and in newer code.
pjc50 10y ago
There are two separate rants here that aren't delineated well. 1) C++ is too complicated, and therefore hard to reason about and slow to compile. We're going to argue about this forever, but you'll have to agree that the spec is very large and warty compared to other languages, and that C++ tends to take far longer to compile (this was already a problem a decade ago, it's not specific to "modern" C++). 2) The future of software development will include more of what I'm going to call ""non-isotropic"" software; rather than assuming a flat memory model and a single in-order execution unit, and exerting great effort to pretend that that's still the case, programmers will have to develop effectively on GPUs and reconfigurable hardware. Presumably this speculation is based on the Intel-Altera acquisition. You can sort of do hardware programming in C (SystemC) but C++ is really not a good fit for hardware. Personally I'd like to see a cambrian explosion of HDLs, but the time is not yet right for that. It sounds like the author favours the "C with classes" programming style, maybe including smart pointers, and is probably not keen on lambdaization of everything.
- gpderetta 10y ago
  Can't really argue about 1. About 2, in-order single instruction execution hasn't been an assumption for a very long time; c and c++ optimizers (and programmers) have been able to take advantage of these CPU features for a while. There are language extensions (Cilk++, OpenMP), to take advantage of extra cores for fine grained parallelism. Regarding GPUs, arguably C and C++ have the most mature and transparent offloading support all around (OpenACC, again OpenMP, whatever MS offloading extensions are called) and the most popular GPU programming language (CUDA) is a C++ dialect. Regarding the flat memory model, for large scale programming the only sane model is a flat, cache coherent one; those architectures that don't provide that, either evolve to provide it or die (cf. CELL) supplanted by those that do (yes, that doesn't mean that all memory is the same, but that is true with your standard CPU anyway). I don't have an opinion on FPGAs, I expect that, if they ever go mainstream, initially people will just assemble predefined blocks via high level languages, but who knows what the future reserves us.
  - pjc50 10y ago
    Parallelism: yes, although OpenMP isn't nearly as accessible as e.g. Swift async closures. C++ only got proper language-native threading in C++11. for large scale programming the only sane model is a flat, cache coherent one Do google view their datacenters as a single flat cache-coherent memory space? No, they built mapreduce instead. That's the point of view I'm coming from: distributed systems engineering working downwards. Rather than a single large program operating on a single memory space, a set of fragments whose programmers are aware that there is latency when communicating between nodes. DRAM is just another "node" that you have to send messages to and wait for a response.
kangar00 10y ago
> If you cannot figure out in one minute what a C++ file is doing, assume the code is incorrect. This statement at first resonated with me, and then I thought about it: this doesn't reduce the complexity of the overall application or service, it just means that one file is simple. You could have 10,000 files instead of 1 much shorter one; is that any more simple?
- lmm 10y ago
  Yes. If each file makes sense in isolation then the whole will as well. Just splitting code into lots of files won't necessarily produce files that you can figure out in 1 minute though (you have to define the boundaries between files such that they make sense).
  - fjanisze 10y ago
    In my opinion this only shift the problem from coding clean code to handling hundreds or thousands of simple and small source files. This will make much more complicated to handle a large project because everything is scattered in such an extend that a developer spend more time searching thru the include list of files than understanding what the code is actually doing. Implementing complex functionality is going to be a nightmare and the end, everything is going to be merged in a single translation unit anyway. But this is just my personal opinion..
    - lmm 10y ago
      > In my opinion this only shift the problem from coding clean code to handling hundreds or thousands of simple and small source files. This will make much more complicated to handle a large project because everything is scattered in such an extend that a developer spend more time searching thru the include list of files than understanding what the code is actually doing. I've worked on a number of very large codebases and that simply isn't my experience. If code is easy to understand it tends to make good use of the domain language and therefore also be easy to search. > Implementing complex functionality is going to be a nightmare The opposite, in my experience. The only maintainable way to implement complex functionality is to break it into small pieces. > everything is going to be merged in a single translation unit anyway. That's the compiler's business. I don't care one way or the other about its implementation details.
Philipp__ 10y ago
While some pretty good points were stated in this post, I cannot but feel OP is a bit biased. Too narrow sort to say. I feel totally opposite in terms of new Modern C++. I guess the thing is how, where and when you use it will define your opinion/experience.
afsafafaf 10y ago
Wonder if they tried IncrediBuild to reduce their compile time? They are right that C++ - while faster than ever before - takes much longer to compile than many other languages.
- daemin 10y ago
  Things like Incredibuild can only help so much. You still need to have a decent project structure, and enough computers to effectively cut down compile time. Though (as mentioned in another comment) if your project is a big ball of inter dependencies then the link time will dominate. I've seen compile times with Incredibuild that are less than a minute, but the link takes 5-10 minutes. Or better yet crashes due to the pdb size.
ensiferum 10y ago
It just sounds like someone who couldn't handle C++ whining and making a bunch of blanket statements without really having any proper understanding. I agree that some of the features such as lambdas can use to hard to track bugs (lifetime issues) and difficult to follow code when abused. When used nicely though they can lead to simple, elegant and straightforward code (anyone who tried to use the STL algorithms before lambdas knows what a pita it was most of the time). Bottom line, if your code base is a mess don't blame the tool. Blame the programmers.
- userbinator 10y ago
  Bottom line, if your code base is a mess don't blame the tool. Blame the programmers. The problem is the attitude towards these new features that naturally leads to programmers abusing them, building overabstracted complex bloated behemoths to accomplish the simplest of tasks. I'd say the vast majority of programmers, for some reason, seem to have an appetite for complexity --- they tend to feel that overly complicating things somehow makes their code better, especially if they can use some new shiny fancy features in the process. I don't think like that so I don't know exactly why that is the case, but perhaps it has to do with the feeling of accomplishment from having written something "big", solving simple problems with complex solutions. Instead, I'm the opposite --- I like solving complex problems with simple solutions, which means code that is usually very straightforward and only occasionally makes use of some more advanced features of the language, when it helps simplify the solution.
  - to3m 10y ago
    A common assumption among C++ programmers seems to be that if an ounce of prevention is worth a pound of cure, the value of a ton of prevention must scale up similarly. But a ton of anything is too much weight for most projects to handle.
- coldtea 10y ago
  >It just sounds like someone who couldn't handle C++ whining As if you have so more experience and skills than him in the language? He's not some newbie trying C++ for the first time... >Bottom line, if your code base is a mess don't blame the tool. Blame the programmers. If the tool is a programming language, then its syntax, modularization and other features absolutely affect the code being a mess or not. Tools as not passive, they influence how we use them and what we can do with them.
sitkack 10y ago
> "that is where the unicorns are born: by people that can see on both sides of the fence"
DrBazza 10y ago
“There are only two kinds of languages: the ones people complain about and the ones nobody uses.” - Stroustrup. C++30, might end up being D, today.
- dkhenry 10y ago
  Or Rust, or Go. C++ is like Java, it will pull in features of other languages years after they have been proven to be valuable and useful, not that there is anything wrong with that. There is something to be said for a slow moving target that you can kinda rely on to work well. If anything I think C++ went off the rails when they started innovating in the language space and tried to introduce all sorts of novel features that other languages hadn't prototyped. I think of all the nonsense around templates that they introduced and how generally the consensus is not to use any advanced template features.
messel 10y ago
Ok. Try a different language :)? A single language needed to solve all problems is a fallacy. I don't see FPGA programming ousting c++, but expect higher level languages with strong parallel semantics to gain "market share". You can always call a dedicated process written in optimized c for the hottest components. Compose the rest in go, elixir, or any high level language (lisp). Architectures will naturally gravitate to higher level languages that support cleaner composition. The tools and interfaces will push towards higher abstraction without impacting build or run time. Maybe this process is related to Kevin Kelly's inevitable. I'm an optimist here.
- coldtea 10y ago
  >A single language needed to solve all problems is a fallacy. Has that been proven and do we have pointers to any peer reviewed papers on that? Because else its just an old's wives tale. I don't see any logical impossibilities for one language to solve all problems (meaning, to work well for at least 4 domains: OS and drivers a la C, apps/games a la C++, network programming a la Go, Java etc, and scripting a la Python). It's just cultural, monetary, design and community issues with most current languages. And even if we want to have different profiles for each domain, ideally I'd do it with a 2-layered language implementation like this: 1) Base library: network, threads/fibers, UI, database etc of Python/Java SDK proportions 2) A "close-to-the-metal" layer without a (big or any) runtime (can use RAII, ARC, etc). 3) A "scripting" layer that is a GC'ed an easier to use superset of the (2)'s syntax. Ideally all (2) code should also be valid (3) code. Both use the same base library (written in the "metal" layer or C). (3) can be embedded into (2) as a scripting engine, and (3) can call all (2) APIs trivially (e.g. no need for declarations like for using C from Go, Python etc -- just import and call). Programmers can use (2) or (3), mix them, share code between the two. And what's best, the core APIs are all the same -- which is most difficult part to master in a language. (Think like Java and Groovy, but with the parent language closer to the metal and the later closer to C).
  - pjc50 10y ago
    It's just cultural, monetary, design and community issues "What difficulties does this proposal face?" "All of them"
cm3 10y ago
I recently had to switch a project to -std=c++11 because a header I include now uses C++11 files. This change alone made compilation at least twice if not three times as slow. The new safety and convenience features are nice but compile times seem to be out of focus and getting slower and slower every year. I don't know how I feel with g++ 6.1 defaulting to -std=gnu++14.
- netheril96 10y ago
  How do you know that it is c++11 switch that dramatically increased your compile time, instead of the header file and the headers it includes? Two conditions are changed, and you feel confident that one of them is responsible for the outcome. Why?
  - cm3 10y ago
    Because it's a C++11 header that doesn't exist in C++98. And I cannot compile that version without switching to C++11 mode. Edit: there appears to be some confusion here. I don't include the C++11 header myself. I include a public API header of another project which now happens to include a C++11 header in their public include file. Unless I want to stay on the old version of that API and accept the risks, I don't have a choice whether I compile my consumer module in C++11 mode or not. And it's a major fault of the C++ language that there are no modules and therefore this include file overhead and mess. They appear to be working towards a module system, thankfully.
    - netheril96 10y ago
      > Because it's a C++11 header that doesn't exist in C++98. That is supposed to be a fault of C++11?
      - cm3 10y ago
        I don't understand your argument. An upstream project I use put a C++11 header in their public API's header. Now, I also have to build in C++11 language mode. If you're saying it's not the language standard's fault that CXX is slower, sure, but how or why should I differentiate between ISO C++ and g++/clang++ with libstd++/libc++?
jonathankoren 10y ago
I know why I don't like C++ anymore, it's just no fun.Its slow to compile, the errors are like 6 lines long full of template and class hierarchy that makes it hard to understand what exactly happened, and then of course there's the common coding shortcut of declaring everything auto. (What type is this list? I don't know, it's auto all the way down.) Then there's the whole thing about making constructors, but leaving the bodies empty because everything should be on initialize lists now, and now there's wrapped pointers for some reason. I hated writing modern C++. It was just so depressing and frustrating.
- ensiferum 10y ago
  My personal rules for using auto. Only use it iff: 1. the actual type is clearly visible on the right hand side. auto f = make_widget(); // it's a widget auto i = 123; // it's an int auto x = vec3(1.0, 0.0, 0.0); // it's a vector 2. the actual type doesn't really matter so much or is complicated to type out. auto it = vec.begin(); // it's an iterator auto it = // some template expression 3. the actual type is not known i.e. lambdas
  - Aleman360 10y ago
    In a word where most new code is JavaScript, just use auto everywhere. It will be OK.
  - fish2000 10y ago
    These are good rules – as in liquor advertisements, it’s advisable to always accompany a declaration that uses `auto` with a rejoinder in the comments to Please Enjoy Responsibly
  - slavik81 10y ago
    I'm not a huge fan of the first rule. It's valid as stated, but the examples are questionable. I've seen all those in real code, and they're kind of annoying. auto f = make_widget(); // is f of type widget or widget*? auto i = 123; // ok, I guess, but... // int i = 123; is shorter and more clear. auto x = vec3(1.0, 0.0, 0.0); // this can be shorter and simpler. // vec3 x(1.0, 0.0, 0.0);
T3RMINATED 10y ago
If you are writing for Windows and Windows Only there is absolutely no reason you shouldn't be using C#. If you are writing cross-platform C++ i guess but you can also do Java.
jcbeard 10y ago
I have a few problems with this article: >structure leads to complex code that eventually brings down the most desired characteristic of a source code: easiness of understanding. If done well, the structure of things like variadic templates make libraries easier to use, and make coding faster (granted, code bloat can be an issue with N different function signatures). >C++ today is like Fortran: it reached its limits Not quite. Fortran died because well, object oriented programming came out and lots of people like it. And well, C was always more popular regardless so...C-like C++ was the obvious next choice. There is a lot of cruft in any new library, so some things aren't as performant as if you wrote them in say assembly, which is what the author seems to suggest. Yes, if I built a bare metal iostream-like functionality it would be more performant (ha, used the word :) ). People know iostream isn't that performant. Could it be better? Perhaps. Is it safe? Yes! If you want perf, use the C interface directly. Is that safe to use, probably not for the general careless user. >To handle the type of speed that is being delivered in droves by the technology companies, C++ cannot be used anymore because it is inherently serial, even in massively multithreaded systems like GPUs. Well, yes but so is just about every language. People are trained to write sequentially (left to right, top to bottom), with many exceptions...but none the less, sequentially. There are very few languages that do multithreading natively. There are lots of additions/libraries to C++ that enable very nice ways to consider parallelism (including w/in standard: std::thread), outside of standard (raftlib.io,hpx(https://github.com/STEllAR-GROUP/hpx https://github.com/STEllAR-GROUP/hpx),kokkos (https://github.com/kokkos https://github.com/kokkos), etc.). There are lots, some are quite easy to use. C++ is inherently serial, but there is no better way to write. It is fairly easy to pull out "parallel" pieces of code to execute. It is even easier if the programmer gets quick feedback (like the icc loop profiler,etc.) on things like ambiguous references and loop bounds that can be fixed quickly. Interesting read, but don't agree at all.
justsaysmthng 10y ago
HFT is a pretty limited and extreme application case. From what I understand - everything is not enough for HFT - network cards, kernel drivers, cables, etc. You have milliseconds (edit: nanoseconds !) to receive, process and push your orders before someone else does it and gets the prize. It's an arms race between technologists for the purpose of making a small number of people rich. I doubt that these requirements apply to other application fields where C++ is used - and it's used almost everywhere, with great success I might add. In my view C++ is actually a couple of languages mixed into one. The hard part is knowing which part of the language to use for which part of the problem. The "modern" C++ solves a lot of the nuisances of the "old" C++, but you can do without these features just fine. I apply them carefully to my code and so far it's been a pleasant experience. Even if I don't use all of the new features, it's nice to know that I can (and I will some day!). So I don't really buy this rant..
- gaius 10y ago
  Consultants wanna consult.
  - eva1984 10y ago
    Exactly...If the building blocks is simplified enough, they lose their jobs.
- hendzen 10y ago
  Not milliseconds. Nanoseconds. Competitive tick-to-trade times are on the order of 1000ns or less.
  - logicchains 10y ago
    That really depends on the market in question. There are places where you can still make fat stacks with over 100us tick-to-trade time.
  - bogomipz 10y ago
    How do you tune the machine for that type of latency? User space drivers? Could you elaborate? Not having to go beyond L1 cache doesn't mean much if it takes a few milliseconds to get that trade out of the network card and on to the wire right?
blux 10y ago
Anybody got an idea to which video series of Chandler Carruth he is referring to?
- humanrebar 10y ago
  Here's a few: - "Tuning C++: Benchmarks, and CPUs, and Compilers! Oh My!" https://www.youtube.com/watch?v=nXaxk27zwlk https://www.youtube.com/watch?v=nXaxk27zwlk - "Understanding Compiler Optimization" https://www.youtube.com/watch?v=FnGCDLhaxKU https://www.youtube.com/watch?v=FnGCDLhaxKU - "Optimizing the Emergent Structures of C++" https://www.youtube.com/watch?v=eR34r7HOU14 https://www.youtube.com/watch?v=eR34r7HOU14 - "Efficiency with Algorithms" https://www.youtube.com/watch?v=fHNmRkzxHWs https://www.youtube.com/watch?v=fHNmRkzxHWs The first one is really good if you've never benchmarked anything in a Linux environment. Or if you otherwise want to learn how to investigate how C++ gets turned into machine code.
jupp0r 10y ago
In my experience, the opposite of what the author claims is true: modern C++ leads to code that's easier to understand, performs better and is easier to maintain. As an example, replacing boost::bind with lambdas allowed the compiler to inline functor calls and avoided virtual function calls in a large code base I've been working with, improving performance. Move semantics also boosted performance. Designing APIs with lambdas in mind allowed us to get rid of tons of callback interfaces, reducing boilerplate and code duplication. I also found compilation times to be unaffected by using modern C++ features. The main problem is the preprocessor including hundreds of thousands of lines for a single compilation unit. This has been a problem in C and C++ forever and will only be resolved with C++ modules in C++2x (hopefully). I encourage the author to try pasting some of his code into https://gcc.godbolt.org/ https://gcc.godbolt.org/ and to look at the generated assembly. Following the C++ core guidelines (http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines) is also a good way to avoid shooting yourself in the foot (which is surprisingly easy with C++, unfortunately).
- blazespin 10y ago
  I think the author was mostly referring to meta programming / templates. You have to admit, they can get pretty obscure sometimes. I agree, lambdas simplify callbackas/async programming immensely.
  - TillE 10y ago
    Right, but there's nothing "modern" about templates. Those have been a disaster for compile times forever. C++98 with no Boost is an awful language that nobody should want to go back to. It's one where you could legitimately prefer C99, despite its lack of RAII and other conveniences. Actual modern C++ is a great language to write, though the compile times haven't really improved.
    - moron4hire 10y ago
      Given the position that system quality is directly proportional to frequency of testing, in what ways can a C++ project from-the-ground-up mitigate compile times and be reactive to change?
n00b101 10y ago
As has always been the case, effective use of modern C++ requires knowing which subset of the language to use and which to avoid. I agree with the author's criticisms of many C++ features. At the same time, I think that a proper simple, modern subset of C++ exists that is much more productive and safer than C, without sacrificing performance. You can also optimize progressively, for example start with using std::string and std::vector and then replace the stock implementations if they aren't performant on your target architecture. I would not, however, recommend using C++ for GPU kernel code - a mix of C++ for CPU code and C for GPU kernel code works best. It is not ideal, but it's the best toolset available for serious industrial development. FPGAs are exciting, but they've also been the "next big thing" in general purpose computing forever. Obviously it makes sense to use FPGAs for certain HFT and embedded applications, but that's not the same as general purpose computing which is what C/C++ is for. Not to mention, FPGA compile times can take hours or even days, which pales in comparison to most C++ template overhead. I would also say that for IOT, I'm not sure why it is obvious that "$10 FPGAs" should dominate. Why not a $0.50 microcontroller? Or the $5 Raspberry Pi Zero board? Both of which are eminently programable in C and even C++. Embedded devices have been around long before "IOT" became a buzzword, and we can see that microcontrollers, FPGAs, SOCs, and custom ASICs all have a role to play depending on the application.
- nickpsecurity 10y ago
  "Not to mention, FPGA compile times can take hours or even days, which pales in comparison to most C++ template overhead." It's really funny to see him bitching about iterations with templates then suggest using a FPGA and synthesis tools. I'm glad it amused someone else, too. :)
koyote 10y ago
Am I the only one being redirected to a linkedin sign up screen?
- nas 10y ago
  I'm redirected too. I'm not signing up with Linked-In, agreeing to their policies, letting them spam me, etc just so I can read this article.
cpwright 10y ago
I find the beginning and end of the article quite contradictory. Basically that C++ is too complicated; and oh by the way we should start programming FPGAs, which are much harder to get right. I like modern C++, because I think it simplifies a lot of things (RAII for the win here). Templates let you engage in duck typing, but with (if you are careful) very performant results.
typon 10y ago
If he is complaining about C++ being bad and suggesting Verilog on FPGAs as an alternative, boy do I have some bad news for him. HDLs (yes including Systemverilog) have 10x worse design than the worst software languages. This is why there are entire companies out there that make high level synthesis tools or high level HDL specification languages (like Bluespec). And I haven't even said anything about the quality of FPGA tool chains.
- deng 10y ago
  This, a thousand times. If you want minimum latency, FPGAs are of course a possible solution, but selling it as a "better C++" is just laughable. When you have an IP core which fits your problem, then by all means use it (and hope it works as advertised), but otherwise: the less you need to do in an FPGA, the better.
je42 10y ago
Actually, the Author wants GO.
aninteger 10y ago
I've come to the conclusion that one should "use C++ when they absolutely have to and C when you can." There just aren't many areas where C++ is absolutely required when plain old simple C can be used. (Not to mention using higher languages if possible).
ausjke 10y ago
Just started to relearn c++ and QT for cross-platform GUI programs, c++ is not easy, but its performance is still unbeatable and in certain use cases, e.g. games or video-related-performance-critical-apps or GPU-opencl-etc, c++ seems to be the sole candidate still.
HemanHeartYou 10y ago
just another rant from someone thats a little fed up with working in x language
shanwang 10y ago
Such rant appears once every few months on HN, this one is one of the least convincing. Many problems he mentioned are not "Modern C++" problems, but problems with C++ from beginning, some of them already have reasonable solutions, for example ccache + distcc for speeding up compilation. The real problem with C++ is the standard committee, the design by committee approach for such a complex language is failing. If C++ is taken over by a company, it will be a much better language.
known 10y ago
Me too :)
known 10y ago
Kernel is my new home;
mlvljr 10y ago
Amen.
sickbeard 10y ago
His argument about simplicity resonates with me. Sure you can learn variadic templates and all that fancy stuff but in practice when you are working on production software in any company involving more than one person using the code base, it just pays in heaps to write the simplest easiest to understand code; meaning all that nice fancy stuff is almost never used.
M1ntos123 10y ago
If C++ were able to ditch legacy things from both the standard and the implmentations it would perhaps create some wriggleroom for radical improvements?
deleted 10y ago
[deleted]
dahart 10y ago
> Today the "Modern Technologist" has to rely on a new set of languages: Verilog, VHDL That was a complete surprise ending! :) I like surprise endings, and he makes a lot of good points, whether or not I agree with them. But, I totally wasn't expecting "I'm done with C++ because: hardware." I was expecting because web or because awesome new high performance functional scripting language <X>. A lot of what he's talking about there will still run compiled software though... FPGA programming and C++ aren't exactly mutually exclusive, right?
- pjc50 10y ago
  FPGA programming and C++ aren't exactly mutually exclusive, right? I would say yes: you can't really run C++ on an FPGA. There are all sorts of tools which promise this (SystemC etc), but it requires you to stick to a careful subset of language constructs. You don't have a heap, for example.
- gpderetta 10y ago
  "FPGA programming and C++ aren't exactly mutually exclusive, right?" Currently they are exclusive. You can theoretically 'compile' some subset of C++ to an FPGA, but you very likely do not want to. Of course C++ makes it a decent language to talk with a custom circuit in FPGA, but that's orthogonal. edit: clarify
progman 10y ago
The problem with modern C++ is that it wants to be everything. Now this behemoth is crushing under its own weight. People who are not forced to use C++ should consider other languages which are way cleaner and even more performant. Code written in Ada and Nim for instance is much easier to maintain.
bitL 10y ago
I agree with the author; I still long for the not-overly-complicated C++ back in the 00s I could write super-fast 3D rendering engine without much bloat. I find it very appalling when C++ went from a poster child of imperative programming to implementing monads in its libraries (mind you, monads are used to "simulate" imperative programming in functional programming). Something went wrong there...
stormbrew 10y ago
One of the biggest users (some would say abusers) of template metaprogramming I know works on HFT software. He trades extremely long compile times for performance at runtime and finds that C++ allows him to do this and maintain a decent architecture (through what amounts to compile-time polymorphism as well as RAII). For him, it's actually the older features of C++ that have no use. He doesn't use deep class inheritance and never touches virtual functions, for example.
hackerweb 10y ago
How are Verilog and VHDL a "new set of languages"? That set has been around 30 years, almost as long as C with classes.
thinkpad20 10y ago
> After 1970 with the introduction of Martin-Löf's Intuitionistic Type Theory, an inbreed of abstract math and computer science, a period of intense research on new type languages as Agda and Epigram started. This ended up forming the basic support layer for functional programming paradigms. All these theories are taught at college level and hailed as "the next new thing", with vast resources dedicated to them. This seems pretty dubious. Dependently typed languages and other projects embracing advanced type theory are still the realm of niche enthusiasts. While some of the more academic colleges might teach them in one or two courses, the vast majority of education a CS college student receives will be taught in traditional imperative languages. If "vast resources" have been devoted to Agda and Epigram, then I'm not sure what kind of language should be used to describe the resources devoted to C, C++, Java, etc. Also as the author mentions, Intuitionistic Type Theory has been around since the 70's, in fact the same year that C was introduced. Certainly it hasn't been taking over the CS world by storm since its inception, as he seems to claim. Beyond that, the author's argument seems to be a bit incoherent. He critiques the readability of Modern C++, but C++ is notoriously hard to understand, including or especially prior to the development of C++11. It's never going to be an easy language to read except to seasoned developers. If anything, modern C++11 seems to provide abstractions that increase readability and safety. He critiques the performance of modern C++, but then he ends up recommending that people ditch C++ entirely and learn VHDL/verilog instead. Not even vanilla C++ is fast enough for him, then why criticize modern C++ on the grounds of performance?
frozenport 10y ago
Being an expert FPGA programmer is easy, the problem is that small things take a really, really long time.
halayli 10y ago
This article is coming from a frustrated developer and lacks any scientific evidence. The frustration (understandably) is coming from the overwhelming complex new features and patterns that barely a compiler can understand. C++11 onward revamped the language to make up for the lack of progress in the past 10 years. The majority of C++ developers that aren't keeping up with the new features because they are busy with their daily jobs feel that they are falling behind and the language they thought they new has changed underneath them. C++03 already had a steep learning curve, but with C++11+ that learning curve is orders of magnitude more. On the upside, you can use C++11 without understanding most of the details and it will do the right thing most of the them. And I think that's the bet that the language is making.
aspiringuser 10y ago
20 year C++ programmer here. I work on multithreaded server code. Stopped using modern C++ features 5 years ago. I'd compare my use of C++ to be roughly equivalent to the use of C++ in the NodeJS project or the V8 project. I'm not a user of Boost. I have to agree with the author of the article. It takes longer to train developers to write idiosyncratic modern C++ code and compilation times explodes. Compiler support for bleeding edge C++ features is spotty at best. Harder to reason about the correctness of modern C++ code.
- Const-me 10y ago
  15 years here. I'm mostly in MS ecosystem, so I don't have issues with C++ compiler support. But I totally agree with the rest of your comment.
Nano2rad 10y ago
Functional language programs have to run as interpreted. If compiled they will be too bloated.
Const-me 10y ago
I never programmed HFT software, but I agree with the criticism of the modern C++. It’s bad the author hasn’t defined what exactly’s “modern” is. I saw some comments compared boost with C++/14. I think boost is also modern. Even Alexandrescu’s Loki is also modern, despite the book was published in 2001. I think that modern stuff was introduced in C++ because in end 90s-start 2000s there was expectation C++ will remain dominant for some time. There was desire to bring higher-level features to the language, to make it easier to learn and safer to use — even at the cost of performance. People didn’t expect C++ will lose its market that fast: very few people now use C++ for web apps or rich GUI. However, due to the inertia and backward compatibility, the features remain in the language. Personally, I’m happy with C++. C++ is excellent for system programming, also for anything CPU bound. For those you barely need those modern features, and fortunately, they’re completely optional: if you don’t like them, don’t use them. But if you do need higher-level language for less performance-critical parts of the project, I find it better to use another higher-level language and integrate it with that C++ library. Depending on the platform, such higher-level language could be C#, Lua, Python, or anything else that works for you.
syngrog66 10y ago
I was once a C++ programmer but migrated first to Java, when I thought it was better designed and more convenient, and then to Python when I wanted less verbosity while having greater freedom to choose between a procedural style or OO. C++ may still be an ideal choice in some problem spaces but I think the number and size of them has shrunk as more and better alternate choices have appeared and ate away at the C++ share.

276 points by nkurz 10y ago

This sounds like it's written from the point of view of implementing something inhouse. I fail to see how FPGA programming will be relevant if one wants to distribute software for consumers (or am I technologically clueless...).

ishi 10y ago
According to the writer's LinkedIn profile, he comes from the world of High Frequency Trading. That's an area where performance is so important, that it might make sense to design your own hardware. And you certainly don't want to distribute it to anyone... I do agree with the writer that with each release, C++ has become more and more complicated, seriously hurting the maintainability of C++ code.
- entelechy 10y ago
  I also agree that c++ is getting more and more complex over time. However if you build things from scratch and you cherry pick your language features, C++ can be quite pleasant.
  - TheOtherHobbes 10y ago
    That's the problem - C++ isn't one language, it's at least three generations of languages living together in the same compiler, like an extended family crammed into a tiny apartment. No one has moved out since 1983, and new additions just keep on coming.
    - gpderetta 10y ago
      We c++ programmers are very welcoming. We have yet to meet a paradigm that we didn't like. On a more serious note, any old system acquires cruft with time and you don't always have the luxury of throwing away pieces or even restarting from scratch.
  - ishi 10y ago
    It may be pleasant for you, but not so pleasant for the next developer who needs to maintain your code. Perhaps he likes picking different cherries than yours...
- daemin 10y ago
  So it seems like he wants people to learn FPGA based programming languages (Verilog, VHDL) because he will need to hire (more of?) these people soon.
easytiger 10y ago
Sounds like he is suffering from bias of the problem domain he is working on right now.
- asveikau 10y ago
  Which, to be fair, is also an apt description of defenders of C and C++ (I consider myself in that category). We are all susceptible to the biases of niches we have worked in and what we have seen working well in those niches. C and C++ can be made to shine in some ways that I get the strong impression many people who happen to not have the same experiences will never appreciate, and perhaps that's not even a bad thing, maybe that just is.
- adrianratnapala 10y ago
  But that problem domain is dominated by the need for speed -- which is exactly where C and C++ are supposed to have a competitive advantage.

hellofunk 10y ago

This article is not very general. Much of what it tries to convince us is not going to matter for most developers, and has the cost of suggesting modern features are not good for any developers. For example: >It is not rare to see Modern C++ applications taking 10 minutes to compile. With traditional C++, this number is counted in low seconds for a simple change. This is simply a bogus statement with respect to what at least 90% of c++ developers do on a daily basis. I have benchmarked unique_ptr, auto, brace initialization, lambdas, range-based-for and other modern idioms and found them all to be at least as fast, and often faster, than their older counterparts. Now, if I were to instead go off and write template-heavy code using new features, that would be different. But in reality, the vast majority of c++ developers -- I'd wager at least 95% -- are not writing variadic templates on a daily basis (nor should they be). The memory safety and many benefits from unique_ptr [0] is one of many modern tools that is a non-brainer to use in nearly all contexts. No, not nearly all contexts, allow me to rephrase: all contexts. It just is, and if you compare its use to manual new/delete code, the benefits are solid and faster. The author further claims that modern C++ is less maintainable and more complex. The absolute opposite is true in nearly all cases. Using unique_ptr again as an example, it leads to less code, less complex code, more clear code, and better maintainability and code readability. Uniform brace initialization is another example that prevents many common older problems in the language. FYI the author keeps talking about high frequency trading as an example of why modern c++ is a bad choice. Well, I worked at a HFT firm for a long time until last year, the firm places millions of trades per day and is among the most successful in the markets it trades. And what did we use? Only modern features. Lambdas, auto, unique_ptr, range-fors, even std::async -- everywhere in our code. This author is either naive or political. I think the title of this article is highly misleading, and the contents are not relevant. Overall, this article is just bad advice for most of us. [0] https://news.ycombinator.com/item?id=11699954 https://news.ycombinator.com/item?id=11699954

daemin 10y ago
I got the feeling that the author's beef with Modern C++ is the same as for any C++ that is template heavy. And to me it is not a new or unique experience (i.e. not limited to Modern C++) to have builds that take 45 minutes to build everything. It can happen in older code and in newer code.

pjc50 10y ago

There are two separate rants here that aren't delineated well. 1) C++ is too complicated, and therefore hard to reason about and slow to compile. We're going to argue about this forever, but you'll have to agree that the spec is very large and warty compared to other languages, and that C++ tends to take far longer to compile (this was already a problem a decade ago, it's not specific to "modern" C++). 2) The future of software development will include more of what I'm going to call ""non-isotropic"" software; rather than assuming a flat memory model and a single in-order execution unit, and exerting great effort to pretend that that's still the case, programmers will have to develop effectively on GPUs and reconfigurable hardware. Presumably this speculation is based on the Intel-Altera acquisition. You can sort of do hardware programming in C (SystemC) but C++ is really not a good fit for hardware. Personally I'd like to see a cambrian explosion of HDLs, but the time is not yet right for that. It sounds like the author favours the "C with classes" programming style, maybe including smart pointers, and is probably not keen on lambdaization of everything.

gpderetta 10y ago
Can't really argue about 1. About 2, in-order single instruction execution hasn't been an assumption for a very long time; c and c++ optimizers (and programmers) have been able to take advantage of these CPU features for a while. There are language extensions (Cilk++, OpenMP), to take advantage of extra cores for fine grained parallelism. Regarding GPUs, arguably C and C++ have the most mature and transparent offloading support all around (OpenACC, again OpenMP, whatever MS offloading extensions are called) and the most popular GPU programming language (CUDA) is a C++ dialect. Regarding the flat memory model, for large scale programming the only sane model is a flat, cache coherent one; those architectures that don't provide that, either evolve to provide it or die (cf. CELL) supplanted by those that do (yes, that doesn't mean that all memory is the same, but that is true with your standard CPU anyway). I don't have an opinion on FPGAs, I expect that, if they ever go mainstream, initially people will just assemble predefined blocks via high level languages, but who knows what the future reserves us.
- pjc50 10y ago
  Parallelism: yes, although OpenMP isn't nearly as accessible as e.g. Swift async closures. C++ only got proper language-native threading in C++11. for large scale programming the only sane model is a flat, cache coherent one Do google view their datacenters as a single flat cache-coherent memory space? No, they built mapreduce instead. That's the point of view I'm coming from: distributed systems engineering working downwards. Rather than a single large program operating on a single memory space, a set of fragments whose programmers are aware that there is latency when communicating between nodes. DRAM is just another "node" that you have to send messages to and wait for a response.

kangar00 10y ago

> If you cannot figure out in one minute what a C++ file is doing, assume the code is incorrect. This statement at first resonated with me, and then I thought about it: this doesn't reduce the complexity of the overall application or service, it just means that one file is simple. You could have 10,000 files instead of 1 much shorter one; is that any more simple?

lmm 10y ago
Yes. If each file makes sense in isolation then the whole will as well. Just splitting code into lots of files won't necessarily produce files that you can figure out in 1 minute though (you have to define the boundaries between files such that they make sense).
- fjanisze 10y ago
  In my opinion this only shift the problem from coding clean code to handling hundreds or thousands of simple and small source files. This will make much more complicated to handle a large project because everything is scattered in such an extend that a developer spend more time searching thru the include list of files than understanding what the code is actually doing. Implementing complex functionality is going to be a nightmare and the end, everything is going to be merged in a single translation unit anyway. But this is just my personal opinion..
  - lmm 10y ago
    > In my opinion this only shift the problem from coding clean code to handling hundreds or thousands of simple and small source files. This will make much more complicated to handle a large project because everything is scattered in such an extend that a developer spend more time searching thru the include list of files than understanding what the code is actually doing. I've worked on a number of very large codebases and that simply isn't my experience. If code is easy to understand it tends to make good use of the domain language and therefore also be easy to search. > Implementing complex functionality is going to be a nightmare The opposite, in my experience. The only maintainable way to implement complex functionality is to break it into small pieces. > everything is going to be merged in a single translation unit anyway. That's the compiler's business. I don't care one way or the other about its implementation details.

Philipp__ 10y ago

While some pretty good points were stated in this post, I cannot but feel OP is a bit biased. Too narrow sort to say. I feel totally opposite in terms of new Modern C++. I guess the thing is how, where and when you use it will define your opinion/experience.

afsafafaf 10y ago

Wonder if they tried IncrediBuild to reduce their compile time? They are right that C++ - while faster than ever before - takes much longer to compile than many other languages.

daemin 10y ago
Things like Incredibuild can only help so much. You still need to have a decent project structure, and enough computers to effectively cut down compile time. Though (as mentioned in another comment) if your project is a big ball of inter dependencies then the link time will dominate. I've seen compile times with Incredibuild that are less than a minute, but the link takes 5-10 minutes. Or better yet crashes due to the pdb size.

ensiferum 10y ago

It just sounds like someone who couldn't handle C++ whining and making a bunch of blanket statements without really having any proper understanding. I agree that some of the features such as lambdas can use to hard to track bugs (lifetime issues) and difficult to follow code when abused. When used nicely though they can lead to simple, elegant and straightforward code (anyone who tried to use the STL algorithms before lambdas knows what a pita it was most of the time). Bottom line, if your code base is a mess don't blame the tool. Blame the programmers.

userbinator 10y ago
Bottom line, if your code base is a mess don't blame the tool. Blame the programmers. The problem is the attitude towards these new features that naturally leads to programmers abusing them, building overabstracted complex bloated behemoths to accomplish the simplest of tasks. I'd say the vast majority of programmers, for some reason, seem to have an appetite for complexity --- they tend to feel that overly complicating things somehow makes their code better, especially if they can use some new shiny fancy features in the process. I don't think like that so I don't know exactly why that is the case, but perhaps it has to do with the feeling of accomplishment from having written something "big", solving simple problems with complex solutions. Instead, I'm the opposite --- I like solving complex problems with simple solutions, which means code that is usually very straightforward and only occasionally makes use of some more advanced features of the language, when it helps simplify the solution.
- to3m 10y ago
  A common assumption among C++ programmers seems to be that if an ounce of prevention is worth a pound of cure, the value of a ton of prevention must scale up similarly. But a ton of anything is too much weight for most projects to handle.
coldtea 10y ago
>It just sounds like someone who couldn't handle C++ whining As if you have so more experience and skills than him in the language? He's not some newbie trying C++ for the first time... >Bottom line, if your code base is a mess don't blame the tool. Blame the programmers. If the tool is a programming language, then its syntax, modularization and other features absolutely affect the code being a mess or not. Tools as not passive, they influence how we use them and what we can do with them.

sitkack 10y ago

> "that is where the unicorns are born: by people that can see on both sides of the fence"

DrBazza 10y ago

“There are only two kinds of languages: the ones people complain about and the ones nobody uses.” - Stroustrup. C++30, might end up being D, today.

dkhenry 10y ago
Or Rust, or Go. C++ is like Java, it will pull in features of other languages years after they have been proven to be valuable and useful, not that there is anything wrong with that. There is something to be said for a slow moving target that you can kinda rely on to work well. If anything I think C++ went off the rails when they started innovating in the language space and tried to introduce all sorts of novel features that other languages hadn't prototyped. I think of all the nonsense around templates that they introduced and how generally the consensus is not to use any advanced template features.

messel 10y ago

Ok. Try a different language :)? A single language needed to solve all problems is a fallacy. I don't see FPGA programming ousting c++, but expect higher level languages with strong parallel semantics to gain "market share". You can always call a dedicated process written in optimized c for the hottest components. Compose the rest in go, elixir, or any high level language (lisp). Architectures will naturally gravitate to higher level languages that support cleaner composition. The tools and interfaces will push towards higher abstraction without impacting build or run time. Maybe this process is related to Kevin Kelly's inevitable. I'm an optimist here.

coldtea 10y ago
>A single language needed to solve all problems is a fallacy. Has that been proven and do we have pointers to any peer reviewed papers on that? Because else its just an old's wives tale. I don't see any logical impossibilities for one language to solve all problems (meaning, to work well for at least 4 domains: OS and drivers a la C, apps/games a la C++, network programming a la Go, Java etc, and scripting a la Python). It's just cultural, monetary, design and community issues with most current languages. And even if we want to have different profiles for each domain, ideally I'd do it with a 2-layered language implementation like this: 1) Base library: network, threads/fibers, UI, database etc of Python/Java SDK proportions 2) A "close-to-the-metal" layer without a (big or any) runtime (can use RAII, ARC, etc). 3) A "scripting" layer that is a GC'ed an easier to use superset of the (2)'s syntax. Ideally all (2) code should also be valid (3) code. Both use the same base library (written in the "metal" layer or C). (3) can be embedded into (2) as a scripting engine, and (3) can call all (2) APIs trivially (e.g. no need for declarations like for using C from Go, Python etc -- just import and call). Programmers can use (2) or (3), mix them, share code between the two. And what's best, the core APIs are all the same -- which is most difficult part to master in a language. (Think like Java and Groovy, but with the parent language closer to the metal and the later closer to C).
- pjc50 10y ago
  It's just cultural, monetary, design and community issues "What difficulties does this proposal face?" "All of them"

cm3 10y ago

I recently had to switch a project to -std=c++11 because a header I include now uses C++11 files. This change alone made compilation at least twice if not three times as slow. The new safety and convenience features are nice but compile times seem to be out of focus and getting slower and slower every year. I don't know how I feel with g++ 6.1 defaulting to -std=gnu++14.

netheril96 10y ago
How do you know that it is c++11 switch that dramatically increased your compile time, instead of the header file and the headers it includes? Two conditions are changed, and you feel confident that one of them is responsible for the outcome. Why?
- cm3 10y ago
  Because it's a C++11 header that doesn't exist in C++98. And I cannot compile that version without switching to C++11 mode. Edit: there appears to be some confusion here. I don't include the C++11 header myself. I include a public API header of another project which now happens to include a C++11 header in their public include file. Unless I want to stay on the old version of that API and accept the risks, I don't have a choice whether I compile my consumer module in C++11 mode or not. And it's a major fault of the C++ language that there are no modules and therefore this include file overhead and mess. They appear to be working towards a module system, thankfully.
  - netheril96 10y ago
    > Because it's a C++11 header that doesn't exist in C++98. That is supposed to be a fault of C++11?
    - cm3 10y ago
      I don't understand your argument. An upstream project I use put a C++11 header in their public API's header. Now, I also have to build in C++11 language mode. If you're saying it's not the language standard's fault that CXX is slower, sure, but how or why should I differentiate between ISO C++ and g++/clang++ with libstd++/libc++?

jonathankoren 10y ago

I know why I don't like C++ anymore, it's just no fun.Its slow to compile, the errors are like 6 lines long full of template and class hierarchy that makes it hard to understand what exactly happened, and then of course there's the common coding shortcut of declaring everything auto. (What type is this list? I don't know, it's auto all the way down.) Then there's the whole thing about making constructors, but leaving the bodies empty because everything should be on initialize lists now, and now there's wrapped pointers for some reason. I hated writing modern C++. It was just so depressing and frustrating.

ensiferum 10y ago
My personal rules for using auto. Only use it iff: 1. the actual type is clearly visible on the right hand side. auto f = make_widget(); // it's a widget auto i = 123; // it's an int auto x = vec3(1.0, 0.0, 0.0); // it's a vector 2. the actual type doesn't really matter so much or is complicated to type out. auto it = vec.begin(); // it's an iterator auto it = // some template expression 3. the actual type is not known i.e. lambdas
- Aleman360 10y ago
  In a word where most new code is JavaScript, just use auto everywhere. It will be OK.
- fish2000 10y ago
  These are good rules – as in liquor advertisements, it’s advisable to always accompany a declaration that uses `auto` with a rejoinder in the comments to Please Enjoy Responsibly
- slavik81 10y ago
  I'm not a huge fan of the first rule. It's valid as stated, but the examples are questionable. I've seen all those in real code, and they're kind of annoying. auto f = make_widget(); // is f of type widget or widget*? auto i = 123; // ok, I guess, but... // int i = 123; is shorter and more clear. auto x = vec3(1.0, 0.0, 0.0); // this can be shorter and simpler. // vec3 x(1.0, 0.0, 0.0);

T3RMINATED 10y ago

If you are writing for Windows and Windows Only there is absolutely no reason you shouldn't be using C#. If you are writing cross-platform C++ i guess but you can also do Java.

jcbeard 10y ago

I have a few problems with this article: >structure leads to complex code that eventually brings down the most desired characteristic of a source code: easiness of understanding. If done well, the structure of things like variadic templates make libraries easier to use, and make coding faster (granted, code bloat can be an issue with N different function signatures). >C++ today is like Fortran: it reached its limits Not quite. Fortran died because well, object oriented programming came out and lots of people like it. And well, C was always more popular regardless so...C-like C++ was the obvious next choice. There is a lot of cruft in any new library, so some things aren't as performant as if you wrote them in say assembly, which is what the author seems to suggest. Yes, if I built a bare metal iostream-like functionality it would be more performant (ha, used the word :) ). People know iostream isn't that performant. Could it be better? Perhaps. Is it safe? Yes! If you want perf, use the C interface directly. Is that safe to use, probably not for the general careless user. >To handle the type of speed that is being delivered in droves by the technology companies, C++ cannot be used anymore because it is inherently serial, even in massively multithreaded systems like GPUs. Well, yes but so is just about every language. People are trained to write sequentially (left to right, top to bottom), with many exceptions...but none the less, sequentially. There are very few languages that do multithreading natively. There are lots of additions/libraries to C++ that enable very nice ways to consider parallelism (including w/in standard: std::thread), outside of standard (raftlib.io,hpx(https://github.com/STEllAR-GROUP/hpx https://github.com/STEllAR-GROUP/hpx),kokkos (https://github.com/kokkos https://github.com/kokkos), etc.). There are lots, some are quite easy to use. C++ is inherently serial, but there is no better way to write. It is fairly easy to pull out "parallel" pieces of code to execute. It is even easier if the programmer gets quick feedback (like the icc loop profiler,etc.) on things like ambiguous references and loop bounds that can be fixed quickly. Interesting read, but don't agree at all.

justsaysmthng 10y ago

HFT is a pretty limited and extreme application case. From what I understand - everything is not enough for HFT - network cards, kernel drivers, cables, etc. You have milliseconds (edit: nanoseconds !) to receive, process and push your orders before someone else does it and gets the prize. It's an arms race between technologists for the purpose of making a small number of people rich. I doubt that these requirements apply to other application fields where C++ is used - and it's used almost everywhere, with great success I might add. In my view C++ is actually a couple of languages mixed into one. The hard part is knowing which part of the language to use for which part of the problem. The "modern" C++ solves a lot of the nuisances of the "old" C++, but you can do without these features just fine. I apply them carefully to my code and so far it's been a pleasant experience. Even if I don't use all of the new features, it's nice to know that I can (and I will some day!). So I don't really buy this rant..

gaius 10y ago
Consultants wanna consult.
- eva1984 10y ago
  Exactly...If the building blocks is simplified enough, they lose their jobs.
hendzen 10y ago
Not milliseconds. Nanoseconds. Competitive tick-to-trade times are on the order of 1000ns or less.
- logicchains 10y ago
  That really depends on the market in question. There are places where you can still make fat stacks with over 100us tick-to-trade time.
- bogomipz 10y ago
  How do you tune the machine for that type of latency? User space drivers? Could you elaborate? Not having to go beyond L1 cache doesn't mean much if it takes a few milliseconds to get that trade out of the network card and on to the wire right?

blux 10y ago

Anybody got an idea to which video series of Chandler Carruth he is referring to?

humanrebar 10y ago
Here's a few: - "Tuning C++: Benchmarks, and CPUs, and Compilers! Oh My!" https://www.youtube.com/watch?v=nXaxk27zwlk https://www.youtube.com/watch?v=nXaxk27zwlk - "Understanding Compiler Optimization" https://www.youtube.com/watch?v=FnGCDLhaxKU https://www.youtube.com/watch?v=FnGCDLhaxKU - "Optimizing the Emergent Structures of C++" https://www.youtube.com/watch?v=eR34r7HOU14 https://www.youtube.com/watch?v=eR34r7HOU14 - "Efficiency with Algorithms" https://www.youtube.com/watch?v=fHNmRkzxHWs https://www.youtube.com/watch?v=fHNmRkzxHWs The first one is really good if you've never benchmarked anything in a Linux environment. Or if you otherwise want to learn how to investigate how C++ gets turned into machine code.

jupp0r 10y ago

In my experience, the opposite of what the author claims is true: modern C++ leads to code that's easier to understand, performs better and is easier to maintain. As an example, replacing boost::bind with lambdas allowed the compiler to inline functor calls and avoided virtual function calls in a large code base I've been working with, improving performance. Move semantics also boosted performance. Designing APIs with lambdas in mind allowed us to get rid of tons of callback interfaces, reducing boilerplate and code duplication. I also found compilation times to be unaffected by using modern C++ features. The main problem is the preprocessor including hundreds of thousands of lines for a single compilation unit. This has been a problem in C and C++ forever and will only be resolved with C++ modules in C++2x (hopefully). I encourage the author to try pasting some of his code into https://gcc.godbolt.org/ https://gcc.godbolt.org/ and to look at the generated assembly. Following the C++ core guidelines (http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines) is also a good way to avoid shooting yourself in the foot (which is surprisingly easy with C++, unfortunately).

blazespin 10y ago
I think the author was mostly referring to meta programming / templates. You have to admit, they can get pretty obscure sometimes. I agree, lambdas simplify callbackas/async programming immensely.
- TillE 10y ago
  Right, but there's nothing "modern" about templates. Those have been a disaster for compile times forever. C++98 with no Boost is an awful language that nobody should want to go back to. It's one where you could legitimately prefer C99, despite its lack of RAII and other conveniences. Actual modern C++ is a great language to write, though the compile times haven't really improved.
  - moron4hire 10y ago
    Given the position that system quality is directly proportional to frequency of testing, in what ways can a C++ project from-the-ground-up mitigate compile times and be reactive to change?

n00b101 10y ago

As has always been the case, effective use of modern C++ requires knowing which subset of the language to use and which to avoid. I agree with the author's criticisms of many C++ features. At the same time, I think that a proper simple, modern subset of C++ exists that is much more productive and safer than C, without sacrificing performance. You can also optimize progressively, for example start with using std::string and std::vector and then replace the stock implementations if they aren't performant on your target architecture. I would not, however, recommend using C++ for GPU kernel code - a mix of C++ for CPU code and C for GPU kernel code works best. It is not ideal, but it's the best toolset available for serious industrial development. FPGAs are exciting, but they've also been the "next big thing" in general purpose computing forever. Obviously it makes sense to use FPGAs for certain HFT and embedded applications, but that's not the same as general purpose computing which is what C/C++ is for. Not to mention, FPGA compile times can take hours or even days, which pales in comparison to most C++ template overhead. I would also say that for IOT, I'm not sure why it is obvious that "$10 FPGAs" should dominate. Why not a $0.50 microcontroller? Or the $5 Raspberry Pi Zero board? Both of which are eminently programable in C and even C++. Embedded devices have been around long before "IOT" became a buzzword, and we can see that microcontrollers, FPGAs, SOCs, and custom ASICs all have a role to play depending on the application.

nickpsecurity 10y ago
"Not to mention, FPGA compile times can take hours or even days, which pales in comparison to most C++ template overhead." It's really funny to see him bitching about iterations with templates then suggest using a FPGA and synthesis tools. I'm glad it amused someone else, too. :)

koyote 10y ago

Am I the only one being redirected to a linkedin sign up screen?

nas 10y ago
I'm redirected too. I'm not signing up with Linked-In, agreeing to their policies, letting them spam me, etc just so I can read this article.

cpwright 10y ago

I find the beginning and end of the article quite contradictory. Basically that C++ is too complicated; and oh by the way we should start programming FPGAs, which are much harder to get right. I like modern C++, because I think it simplifies a lot of things (RAII for the win here). Templates let you engage in duck typing, but with (if you are careful) very performant results.

typon 10y ago

If he is complaining about C++ being bad and suggesting Verilog on FPGAs as an alternative, boy do I have some bad news for him. HDLs (yes including Systemverilog) have 10x worse design than the worst software languages. This is why there are entire companies out there that make high level synthesis tools or high level HDL specification languages (like Bluespec). And I haven't even said anything about the quality of FPGA tool chains.

deng 10y ago
This, a thousand times. If you want minimum latency, FPGAs are of course a possible solution, but selling it as a "better C++" is just laughable. When you have an IP core which fits your problem, then by all means use it (and hope it works as advertised), but otherwise: the less you need to do in an FPGA, the better.

je42 10y ago

Actually, the Author wants GO.

aninteger 10y ago

I've come to the conclusion that one should "use C++ when they absolutely have to and C when you can." There just aren't many areas where C++ is absolutely required when plain old simple C can be used. (Not to mention using higher languages if possible).

ausjke 10y ago

Just started to relearn c++ and QT for cross-platform GUI programs, c++ is not easy, but its performance is still unbeatable and in certain use cases, e.g. games or video-related-performance-critical-apps or GPU-opencl-etc, c++ seems to be the sole candidate still.

HemanHeartYou 10y ago

just another rant from someone thats a little fed up with working in x language

shanwang 10y ago

Such rant appears once every few months on HN, this one is one of the least convincing. Many problems he mentioned are not "Modern C++" problems, but problems with C++ from beginning, some of them already have reasonable solutions, for example ccache + distcc for speeding up compilation. The real problem with C++ is the standard committee, the design by committee approach for such a complex language is failing. If C++ is taken over by a company, it will be a much better language.

known 10y ago

Me too :)

known 10y ago

Kernel is my new home;

mlvljr 10y ago

Amen.

sickbeard 10y ago

His argument about simplicity resonates with me. Sure you can learn variadic templates and all that fancy stuff but in practice when you are working on production software in any company involving more than one person using the code base, it just pays in heaps to write the simplest easiest to understand code; meaning all that nice fancy stuff is almost never used.

M1ntos123 10y ago

If C++ were able to ditch legacy things from both the standard and the implmentations it would perhaps create some wriggleroom for radical improvements?

deleted 10y ago

[deleted]

dahart 10y ago

> Today the "Modern Technologist" has to rely on a new set of languages: Verilog, VHDL That was a complete surprise ending! :) I like surprise endings, and he makes a lot of good points, whether or not I agree with them. But, I totally wasn't expecting "I'm done with C++ because: hardware." I was expecting because web or because awesome new high performance functional scripting language <X>. A lot of what he's talking about there will still run compiled software though... FPGA programming and C++ aren't exactly mutually exclusive, right?

pjc50 10y ago
FPGA programming and C++ aren't exactly mutually exclusive, right? I would say yes: you can't really run C++ on an FPGA. There are all sorts of tools which promise this (SystemC etc), but it requires you to stick to a careful subset of language constructs. You don't have a heap, for example.
gpderetta 10y ago
"FPGA programming and C++ aren't exactly mutually exclusive, right?" Currently they are exclusive. You can theoretically 'compile' some subset of C++ to an FPGA, but you very likely do not want to. Of course C++ makes it a decent language to talk with a custom circuit in FPGA, but that's orthogonal. edit: clarify

progman 10y ago

The problem with modern C++ is that it wants to be everything. Now this behemoth is crushing under its own weight. People who are not forced to use C++ should consider other languages which are way cleaner and even more performant. Code written in Ada and Nim for instance is much easier to maintain.

bitL 10y ago

I agree with the author; I still long for the not-overly-complicated C++ back in the 00s I could write super-fast 3D rendering engine without much bloat. I find it very appalling when C++ went from a poster child of imperative programming to implementing monads in its libraries (mind you, monads are used to "simulate" imperative programming in functional programming). Something went wrong there...

stormbrew 10y ago

One of the biggest users (some would say abusers) of template metaprogramming I know works on HFT software. He trades extremely long compile times for performance at runtime and finds that C++ allows him to do this and maintain a decent architecture (through what amounts to compile-time polymorphism as well as RAII). For him, it's actually the older features of C++ that have no use. He doesn't use deep class inheritance and never touches virtual functions, for example.

hackerweb 10y ago

How are Verilog and VHDL a "new set of languages"? That set has been around 30 years, almost as long as C with classes.

thinkpad20 10y ago

> After 1970 with the introduction of Martin-Löf's Intuitionistic Type Theory, an inbreed of abstract math and computer science, a period of intense research on new type languages as Agda and Epigram started. This ended up forming the basic support layer for functional programming paradigms. All these theories are taught at college level and hailed as "the next new thing", with vast resources dedicated to them. This seems pretty dubious. Dependently typed languages and other projects embracing advanced type theory are still the realm of niche enthusiasts. While some of the more academic colleges might teach them in one or two courses, the vast majority of education a CS college student receives will be taught in traditional imperative languages. If "vast resources" have been devoted to Agda and Epigram, then I'm not sure what kind of language should be used to describe the resources devoted to C, C++, Java, etc. Also as the author mentions, Intuitionistic Type Theory has been around since the 70's, in fact the same year that C was introduced. Certainly it hasn't been taking over the CS world by storm since its inception, as he seems to claim. Beyond that, the author's argument seems to be a bit incoherent. He critiques the readability of Modern C++, but C++ is notoriously hard to understand, including or especially prior to the development of C++11. It's never going to be an easy language to read except to seasoned developers. If anything, modern C++11 seems to provide abstractions that increase readability and safety. He critiques the performance of modern C++, but then he ends up recommending that people ditch C++ entirely and learn VHDL/verilog instead. Not even vanilla C++ is fast enough for him, then why criticize modern C++ on the grounds of performance?

frozenport 10y ago

Being an expert FPGA programmer is easy, the problem is that small things take a really, really long time.

halayli 10y ago

This article is coming from a frustrated developer and lacks any scientific evidence. The frustration (understandably) is coming from the overwhelming complex new features and patterns that barely a compiler can understand. C++11 onward revamped the language to make up for the lack of progress in the past 10 years. The majority of C++ developers that aren't keeping up with the new features because they are busy with their daily jobs feel that they are falling behind and the language they thought they new has changed underneath them. C++03 already had a steep learning curve, but with C++11+ that learning curve is orders of magnitude more. On the upside, you can use C++11 without understanding most of the details and it will do the right thing most of the them. And I think that's the bet that the language is making.

aspiringuser 10y ago

20 year C++ programmer here. I work on multithreaded server code. Stopped using modern C++ features 5 years ago. I'd compare my use of C++ to be roughly equivalent to the use of C++ in the NodeJS project or the V8 project. I'm not a user of Boost. I have to agree with the author of the article. It takes longer to train developers to write idiosyncratic modern C++ code and compilation times explodes. Compiler support for bleeding edge C++ features is spotty at best. Harder to reason about the correctness of modern C++ code.

Const-me 10y ago
15 years here. I'm mostly in MS ecosystem, so I don't have issues with C++ compiler support. But I totally agree with the rest of your comment.

Nano2rad 10y ago

Functional language programs have to run as interpreted. If compiled they will be too bloated.

Const-me 10y ago

I never programmed HFT software, but I agree with the criticism of the modern C++. It’s bad the author hasn’t defined what exactly’s “modern” is. I saw some comments compared boost with C++/14. I think boost is also modern. Even Alexandrescu’s Loki is also modern, despite the book was published in 2001. I think that modern stuff was introduced in C++ because in end 90s-start 2000s there was expectation C++ will remain dominant for some time. There was desire to bring higher-level features to the language, to make it easier to learn and safer to use — even at the cost of performance. People didn’t expect C++ will lose its market that fast: very few people now use C++ for web apps or rich GUI. However, due to the inertia and backward compatibility, the features remain in the language. Personally, I’m happy with C++. C++ is excellent for system programming, also for anything CPU bound. For those you barely need those modern features, and fortunately, they’re completely optional: if you don’t like them, don’t use them. But if you do need higher-level language for less performance-critical parts of the project, I find it better to use another higher-level language and integrate it with that C++ library. Depending on the platform, such higher-level language could be C#, Lua, Python, or anything else that works for you.

syngrog66 10y ago

I was once a C++ programmer but migrated first to Java, when I thought it was better designed and more convenient, and then to Python when I wanted less verbosity while having greater freedom to choose between a procedural style or OO. C++ may still be an ideal choice in some problem spaces but I think the number and size of them has shrunk as more and better alternate choices have appeared and ate away at the C++ share.