7 ms·

The calculus here is simple. You have two options: 1) Spend 90% of the time writing performance-neutral code in a modern high-productivity language and 10% on

The calculus here is simple. You have two options: 1) Spend 90% of the time writing performance-neutral code in a modern high-productivity language and 10% on performance-critical code in a modern high-performance language. 2) Write everything in a "performance beast" of a language, spending 90% of your time fighting said language and 10% delivering useful functionality. Bottom line, if you choose option 2, you spend 10x time delivering the same functionality and performance and you force yourself to hire the kind of expensive developers who are willing to waste their time mastering modern C++.

thesmallestcat 10y ago
Why would mastering modern C++ be a waste of time?
- angersock 10y ago
  Because, for better or for worse, every second spent mastering a language is time not spent delivering value. EDIT: How many dollars have you been paid for template metaprogramming? How many contracts have you won because you used the proper const-correctness? Folks, nobody gives two shits about how pretty your CPP (or any code for that matter!) is if it isn't solving their problem right now. More value has been created by decent developers using the boring language features they know well than by people becoming master craftsman.
  - mikeash 10y ago
    If it helps you deliver value faster afterwards then it's a win. Alice starts cutting down a tree with a dull saw, Bob takes the time to sharpen the saw before he starts cutting. It's not sensible to criticize Bob on the basis that his sharpening time is time not spent delivering value.
    - angersock 10y ago
      There is rarely an afterwards in any meaningful sense: https://en.wikipedia.org/wiki/Superiority_%28short_story%29 https://en.wikipedia.org/wiki/Superiority_%28short_story%29 If you want to see your position taken to the extreme, go look at the JS ecosystem right now. Plenty Bob's sharpening their axes to the detriment of both their projects and the community as a whole. As engineers and programmers we like to play with tools and pursue language purity and whatnot--but we cannot fall into the trap of conflating that with sound business practice.
      - mikeash 10y ago
        Pretty much any idea becomes stupid when taken to an extreme. If you want to see your position taken to the extreme, go look at 90% of programmers out there, who spend as little time as possible sharpening their saw and as much time as possible churning out awful, nearly worthless code.
        angersock 10y ago
        Quantity has a quality all its own, my friend. Wordpress is garbage, but has a fairly secure niche that is only recently even getting attention from competitors. Here on HN everyone is a PLT prodigy who would never deign to admit that they would ever be beaten by the 90% of programmers--but in the real world, well, they make shit happen. Some problems are solved better by throwing warm bodies with lukewarm IQs than by trying to get the perfect language lawyer. Have some humility.
        mikeash 10y ago
        They make shit happen, until it finally collapses in on itself and the people paying the bills realize they've been paying for actual shit, then they bring in a programmer with a sharp saw to clean up the mess. Happens constantly.
        angersock 10y ago
        And that shit paid the bills for the eventual cleanup, while waiting on a better solution wouldn't have. Moreover, it's usually pretty obvious how to fix that kind of mess whereas a more clever/advanced solution can be completely unmaintainable.
  - candiodari 10y ago
    Thing is, there's a number of job types in IT. There's the frontend jobs that everyone can "easily" get into (but that means they aren't good, unfortunately the frontend devs market definitely suffers from lemon law syndrome). C++ backend jobs have a number of great properties: devs are scarce, because of the difficulty interviews will definitely reveal good vs bad, it's an absolute necessity to have these devs, and the products they produce outperform. Ergo mucho dinero. And NOBODY goes to a C++ dev with a photoshop file asking for things to be moved over a few pixels. Nobody. That, by itself ... And to top it all off : because C++ is a mature language the tooling is actually passable to good. In frontend, VSCode+typescript is the only thing I know of that has passable tooling. Passable meaning that editing code is good to well done. Debugging, performance measurement, deployment, monitoring, ... very much not solved. And there's a lot of things that are adding insult to injury. Performance programming also has the advantage that there's problems that just can't be solved by anything that's more than 5% or so removed from optimal performance. And those are really interesting problems : from machine learning to gaming. When I say "can't" I don't literally mean can't, just that a company like Google or Facebook simply can't risk the other one using C++ and not using C++ themselves, due to the risk that it results in the other one getting a 50% faster stack, as they would fear that would be an overriding advantage (and advantage big enough that nothing else matters. Working with a double as fast stack, a mediocre data scientist can outperform a good one, resulting in more advancement, resulting in first-to-market, resulting in). And this applied not just to machine learning, but it applied to games, to databases, to OS, to ... C++ has conquered the machine learning stack, and it's never letting go. The point is that this is not C++'s first rodeo so to speak. C++ has conquered many markets that will never go back to non-C++. And those are exactly the ones you want to work in. But yes, it's pretty serious in the learning curve. And a subtle language results in subtle problems. That generates a ton of hate. One last advantage though : if you're an expert in C++, you're not far removed from being an expert in a lot of different (imperative) languages. C++ has options to do anything, so learning a new language is figuring out how some new language maps onto C++, and getting past the frustration that lots of things just aren't possible in the new language.
    - stevedonovan 10y ago
      My (limited) experience with Rust is that it's necessary to unlearn a lot of C++ habits. E.g. forgetting that Rust likes to _move_ and C++ likes to _copy_
hellofunk 10y ago
You forgot option 3), which I use myself: Write in a high-performance language that also has high-level features, and write 90% of your code without concern for the language's cool optimization features. That's what I do and it's great. I don't use move semantics or think about them, I avoid heavy templates, and I focus a lot of my work on the functional tools in C++ now and the more elegant ways of doing stuff at a high level. For when I need those extra optimizations, no need to change languages, I'm already there.
- ced 10y ago
  Haven't used C++ in a decade - how is the modern functional programming working out without a GC? Isn't object ownership tricky to untangle? I read your option 3 and nodded - I'm using Julia for much the same reasons. I didn't expect C++ to be the answer, but it's cool that it can work out.
  - cjhanks 10y ago
    If you are using Julia, then I will presume you are primarily working in some form of numerical computing. It is a very wide field, so it is difficult to say if object ownership will be tricky or not. If you are working with (b|m)illions of particles or entities which are capable of changing ownership, you will have a hard time in any language. Whether that's the C++ ownership being unclear or the garbage collector defragmenting your memory (just because you don't see the issue doesn't means it's gone in GC languages). That said, typically I find most algorithms have a computable upper-bound memory constraint and so you just pre-allocate a slab and then objects reference it. You will usually get better cache coherency and less wasted operations/sec. You're left with only a couple pointers you need to delete when you're done with the structure. As for `functional programming`, it depends on what you're looking for. C++ has two killer features for this, in my opinion; expression templates can seriously improve performance of functional composition (see Eigen3), and compile-time elision of type-dependent code branches (like a static if). Since I have learned to use `unique_ptr`, `shared_ptr`, `weak_ptr`, (`deferred_ptr`), and to prefer idiomatic accessors like `.at`, `.find`, `.insert` I cannot recall the last time Valgrind was angry at me. I think I end up writing `new` and `delete` maybe once a month(?). If I was designing widgets or applications with hard to define user interaction, I imagine I would have more complaints to share.
ahamino 10y ago
Applications that employ computer vision, machine learning or even deep learning, especially if they are trying to run models on mobile devices have to write their codebases on an efficient high-performance language otherwise, their apps will be just too computationally expensive (too slow). At my company, three quarters of our codebase is written in C++ because performance is very critical for us, in addition portability! i.e we can compile to run the same code on different platforms without added layers of translation.
EpicEng 10y ago
Perhaps this is true for your applications (and why no option 3: developer knows C++ well and is efficient in it?), but not all of us can goof around with GC's and a complete lack of performance oriented features. Not all of us have a huge runtime to support our language which runs on our target platform. Not all of us write code which is 90% boring, UI or CRUD type stuff. Not all of us are ok with delivering bloated applications that require hardware upgrades to run at the same speed they ran at 5 years ago.
- AlexandrB 10y ago
  > but not all of us can goof around with GC's and a complete lack of performance oriented features. But apparently you CAN goof around with KLOCs of useless boilerplate and the added defects they imply [1]. [1] http://programmers.stackexchange.com/questions/185660/is-the-average-number-of-bugs-per-loc-the-same-for-different-programming-languag http://programmers.stackexchange.com/questions/185660/is-the...
  - nurettin 10y ago
    I am fine with IDEs generating boilerplate. I am not fine with maintaining it unless it is easy to navigate to parts of code concerning what needs to be maintained. I live in a 20 year old MLOC land and whenever we need to add or change a subtle behavior, we go debugging for half an hour at best.
user5994461 10y ago
Use java, C#, or Go. You get the high productivity AND the performance together. (Also, the tooling is so much better).
erichocean 10y ago
> Spend 90% of the time writing performance-neutral code in a modern high-productivity language That's actually C++ now. I moved to it from TypeScript earlier this year and have been very happy. (Using Google's Bazel for builds has been really nice, too—I hadn't realized how much I missed having a non-OS-specific package manager.)
cubaia 10y ago
The key here is to distinguish from the pedantic snobs from good developers. The pedantic snob will usually hold some extreme position about topics such as (1) obscure language minutia; (2) endless "framework building"; (3) premature optimization; or (4) mindless design "best practices". They will have high pride attached to whatever is it and they would add a flair of expertise to it, making you feel like you hired a genius. At the start, it looks like they are working on some super advanced wizardry, but you eventually find that they mostly waste time. On the other hand, the good developers care more about delivering value. The good developer will not waste time solving problems you don't have --thus slicing through your 90% problem like butter-- and at the same time will possess the sharp tools to solve the hard 10% problems your less than good developer is unable solve no matter the deadline. For option 1, you hire a good developer. For option 2, you hire a snob. If you hire your average cheap engineer, you get option 0: he/she will eventually do OK for 90% of the problems, but the last 10% (which is often critical) will be a mess.
lbrandy 10y ago
> Spend 90% of the time writing performance-neutral code in a modern high-productivity language and 10% on performance-critical code in a modern high-performance language. What about the other 80% of your time spent trying to get those things to inter-operate in a way that doesn't destroy the good parts of both?
pif 10y ago
> spending 90% of your time fighting said language I've been developing in C++ for more than ten year, and never did I feel the need to fight it. Actually, it was a nice travel companion. And I miss it since I was forced to switch to C#: C++ made all it could to help me do what I needed, and it was effective and smart; C# always tries to convince me to change my needs in order to do things like he prefers. In other word, C++ treated me like a professional partner; C# treats me like a newbie.

thesmallestcat 10y ago

Why would mastering modern C++ be a waste of time?

angersock 10y ago
Because, for better or for worse, every second spent mastering a language is time not spent delivering value. EDIT: How many dollars have you been paid for template metaprogramming? How many contracts have you won because you used the proper const-correctness? Folks, nobody gives two shits about how pretty your CPP (or any code for that matter!) is if it isn't solving their problem right now. More value has been created by decent developers using the boring language features they know well than by people becoming master craftsman.
- mikeash 10y ago
  If it helps you deliver value faster afterwards then it's a win. Alice starts cutting down a tree with a dull saw, Bob takes the time to sharpen the saw before he starts cutting. It's not sensible to criticize Bob on the basis that his sharpening time is time not spent delivering value.
  - angersock 10y ago
    There is rarely an afterwards in any meaningful sense: https://en.wikipedia.org/wiki/Superiority_%28short_story%29 https://en.wikipedia.org/wiki/Superiority_%28short_story%29 If you want to see your position taken to the extreme, go look at the JS ecosystem right now. Plenty Bob's sharpening their axes to the detriment of both their projects and the community as a whole. As engineers and programmers we like to play with tools and pursue language purity and whatnot--but we cannot fall into the trap of conflating that with sound business practice.
    - mikeash 10y ago
      Pretty much any idea becomes stupid when taken to an extreme. If you want to see your position taken to the extreme, go look at 90% of programmers out there, who spend as little time as possible sharpening their saw and as much time as possible churning out awful, nearly worthless code.
      - angersock 10y ago
        Quantity has a quality all its own, my friend. Wordpress is garbage, but has a fairly secure niche that is only recently even getting attention from competitors. Here on HN everyone is a PLT prodigy who would never deign to admit that they would ever be beaten by the 90% of programmers--but in the real world, well, they make shit happen. Some problems are solved better by throwing warm bodies with lukewarm IQs than by trying to get the perfect language lawyer. Have some humility.
        mikeash 10y ago
        They make shit happen, until it finally collapses in on itself and the people paying the bills realize they've been paying for actual shit, then they bring in a programmer with a sharp saw to clean up the mess. Happens constantly.
        angersock 10y ago
        And that shit paid the bills for the eventual cleanup, while waiting on a better solution wouldn't have. Moreover, it's usually pretty obvious how to fix that kind of mess whereas a more clever/advanced solution can be completely unmaintainable.
- candiodari 10y ago
  Thing is, there's a number of job types in IT. There's the frontend jobs that everyone can "easily" get into (but that means they aren't good, unfortunately the frontend devs market definitely suffers from lemon law syndrome). C++ backend jobs have a number of great properties: devs are scarce, because of the difficulty interviews will definitely reveal good vs bad, it's an absolute necessity to have these devs, and the products they produce outperform. Ergo mucho dinero. And NOBODY goes to a C++ dev with a photoshop file asking for things to be moved over a few pixels. Nobody. That, by itself ... And to top it all off : because C++ is a mature language the tooling is actually passable to good. In frontend, VSCode+typescript is the only thing I know of that has passable tooling. Passable meaning that editing code is good to well done. Debugging, performance measurement, deployment, monitoring, ... very much not solved. And there's a lot of things that are adding insult to injury. Performance programming also has the advantage that there's problems that just can't be solved by anything that's more than 5% or so removed from optimal performance. And those are really interesting problems : from machine learning to gaming. When I say "can't" I don't literally mean can't, just that a company like Google or Facebook simply can't risk the other one using C++ and not using C++ themselves, due to the risk that it results in the other one getting a 50% faster stack, as they would fear that would be an overriding advantage (and advantage big enough that nothing else matters. Working with a double as fast stack, a mediocre data scientist can outperform a good one, resulting in more advancement, resulting in first-to-market, resulting in). And this applied not just to machine learning, but it applied to games, to databases, to OS, to ... C++ has conquered the machine learning stack, and it's never letting go. The point is that this is not C++'s first rodeo so to speak. C++ has conquered many markets that will never go back to non-C++. And those are exactly the ones you want to work in. But yes, it's pretty serious in the learning curve. And a subtle language results in subtle problems. That generates a ton of hate. One last advantage though : if you're an expert in C++, you're not far removed from being an expert in a lot of different (imperative) languages. C++ has options to do anything, so learning a new language is figuring out how some new language maps onto C++, and getting past the frustration that lots of things just aren't possible in the new language.
  - stevedonovan 10y ago
    My (limited) experience with Rust is that it's necessary to unlearn a lot of C++ habits. E.g. forgetting that Rust likes to _move_ and C++ likes to _copy_

hellofunk 10y ago

You forgot option 3), which I use myself: Write in a high-performance language that also has high-level features, and write 90% of your code without concern for the language's cool optimization features. That's what I do and it's great. I don't use move semantics or think about them, I avoid heavy templates, and I focus a lot of my work on the functional tools in C++ now and the more elegant ways of doing stuff at a high level. For when I need those extra optimizations, no need to change languages, I'm already there.

ced 10y ago
Haven't used C++ in a decade - how is the modern functional programming working out without a GC? Isn't object ownership tricky to untangle? I read your option 3 and nodded - I'm using Julia for much the same reasons. I didn't expect C++ to be the answer, but it's cool that it can work out.
- cjhanks 10y ago
  If you are using Julia, then I will presume you are primarily working in some form of numerical computing. It is a very wide field, so it is difficult to say if object ownership will be tricky or not. If you are working with (b|m)illions of particles or entities which are capable of changing ownership, you will have a hard time in any language. Whether that's the C++ ownership being unclear or the garbage collector defragmenting your memory (just because you don't see the issue doesn't means it's gone in GC languages). That said, typically I find most algorithms have a computable upper-bound memory constraint and so you just pre-allocate a slab and then objects reference it. You will usually get better cache coherency and less wasted operations/sec. You're left with only a couple pointers you need to delete when you're done with the structure. As for `functional programming`, it depends on what you're looking for. C++ has two killer features for this, in my opinion; expression templates can seriously improve performance of functional composition (see Eigen3), and compile-time elision of type-dependent code branches (like a static if). Since I have learned to use `unique_ptr`, `shared_ptr`, `weak_ptr`, (`deferred_ptr`), and to prefer idiomatic accessors like `.at`, `.find`, `.insert` I cannot recall the last time Valgrind was angry at me. I think I end up writing `new` and `delete` maybe once a month(?). If I was designing widgets or applications with hard to define user interaction, I imagine I would have more complaints to share.

ahamino 10y ago

Applications that employ computer vision, machine learning or even deep learning, especially if they are trying to run models on mobile devices have to write their codebases on an efficient high-performance language otherwise, their apps will be just too computationally expensive (too slow). At my company, three quarters of our codebase is written in C++ because performance is very critical for us, in addition portability! i.e we can compile to run the same code on different platforms without added layers of translation.

EpicEng 10y ago

Perhaps this is true for your applications (and why no option 3: developer knows C++ well and is efficient in it?), but not all of us can goof around with GC's and a complete lack of performance oriented features. Not all of us have a huge runtime to support our language which runs on our target platform. Not all of us write code which is 90% boring, UI or CRUD type stuff. Not all of us are ok with delivering bloated applications that require hardware upgrades to run at the same speed they ran at 5 years ago.

AlexandrB 10y ago
> but not all of us can goof around with GC's and a complete lack of performance oriented features. But apparently you CAN goof around with KLOCs of useless boilerplate and the added defects they imply [1]. [1] http://programmers.stackexchange.com/questions/185660/is-the-average-number-of-bugs-per-loc-the-same-for-different-programming-languag http://programmers.stackexchange.com/questions/185660/is-the...
- nurettin 10y ago
  I am fine with IDEs generating boilerplate. I am not fine with maintaining it unless it is easy to navigate to parts of code concerning what needs to be maintained. I live in a 20 year old MLOC land and whenever we need to add or change a subtle behavior, we go debugging for half an hour at best.

user5994461 10y ago

Use java, C#, or Go. You get the high productivity AND the performance together. (Also, the tooling is so much better).

erichocean 10y ago

> Spend 90% of the time writing performance-neutral code in a modern high-productivity language That's actually C++ now. I moved to it from TypeScript earlier this year and have been very happy. (Using Google's Bazel for builds has been really nice, too—I hadn't realized how much I missed having a non-OS-specific package manager.)

cubaia 10y ago

The key here is to distinguish from the pedantic snobs from good developers. The pedantic snob will usually hold some extreme position about topics such as (1) obscure language minutia; (2) endless "framework building"; (3) premature optimization; or (4) mindless design "best practices". They will have high pride attached to whatever is it and they would add a flair of expertise to it, making you feel like you hired a genius. At the start, it looks like they are working on some super advanced wizardry, but you eventually find that they mostly waste time. On the other hand, the good developers care more about delivering value. The good developer will not waste time solving problems you don't have --thus slicing through your 90% problem like butter-- and at the same time will possess the sharp tools to solve the hard 10% problems your less than good developer is unable solve no matter the deadline. For option 1, you hire a good developer. For option 2, you hire a snob. If you hire your average cheap engineer, you get option 0: he/she will eventually do OK for 90% of the problems, but the last 10% (which is often critical) will be a mess.

lbrandy 10y ago

> Spend 90% of the time writing performance-neutral code in a modern high-productivity language and 10% on performance-critical code in a modern high-performance language. What about the other 80% of your time spent trying to get those things to inter-operate in a way that doesn't destroy the good parts of both?

pif 10y ago

> spending 90% of your time fighting said language I've been developing in C++ for more than ten year, and never did I feel the need to fight it. Actually, it was a nice travel companion. And I miss it since I was forced to switch to C#: C++ made all it could to help me do what I needed, and it was effective and smart; C# always tries to convince me to change my needs in order to do things like he prefers. In other word, C++ treated me like a professional partner; C# treats me like a newbie.