Quite often, the choice of language is failing to see the forest for the trees. Saving nanoseconds or cycles because you chose C++ over Python pales in comparison to milliseconds spent at network barriers reading from a cache service or database
Perceivable latency isn't the only consideration. Depending on your business, compute for your proprietary workloads might be one of your biggest expenses. You could see an order of magnitude improvement to resource consumption depending on the type of workload and the language it is written in.
Ultimately these these choices are all about trade-offs. Maybe python is fine for them, maybe they've built themselves into a corner. Time will tell.
The difference between C++ and Python is not nanoseconds.
And I have definitely seen projects fail due - in part - to language choice. Of course projects can succeed in almost any language but that doesn't mean the language choice is irrelevant.
Did you read the article and comments? The comments point out a lot of issues with the article. Sadly, I've seen this article referenced before on other discussions.
But do the millions you spend a year on compute cost more or less than the millions you would spend a year in labor finding the increasingly rare breed of C++ developers who can optimize things for instruction or cycle count? Such developers usually have over a decade of experience (if not multiple decades). Python developers are a dime a dozen, comparatively
Plus, instruction and cycle counting is low hanging fruit compared to memory latency. You can cache-optimize a program in any language so long as the memory representation of some data is relatively transparent.
> But do the millions you spend a year on compute cost more or less than the millions you would spend a year in labor finding the increasingly rare breed of C++ developers who can optimize things for instruction or cycle count?
That's a very valid question but in the case of Facebook they already have them so why not use them for that?
I mean yeah, they made their choice -- use HHVM and it likely served them very well. I am just pointing out that in their case sourcing extra (or even any at all) C++ devs is a non-issue because they already have plenty.
