Comment by mrbrowning | Hacker News Reader

Comment by mrbrowning | Hacker News Reader

Parent Full thread

This is myopic in the characteristically self-undermining way that most of these defenses are.

I actually like modern C++ well enough for the niche described here; lambdas (and the control they offer over captured variables), type deduction, ranged fors and the like make it pleasant enough to write for being as performant as it can be. I've written many more lines of C++ than Rust. But it's still apparent that language-enforced invariants are quite a different species from conventions that will enable safe programs if everyone uses them correctly at all times. You can maybe guarantee that for a team, but can you guarantee it for several teams? Can you guarantee it for every external dependency?

I can imagine plenty of pragmatic analyses today ending up with C++ as the ideal choice of language, but the monomaniacal focus on Performance ignores ecological concerns like these and also mostly doesn't grapple with the fact that there's plenty of low-hanging fruit to get to performance-wise in any project before something like a fundamental 1.2x performance penalty on Rust's part really matters, especially considering how domain-dependent that number is likely to be. Pure speed is a pretty poisonous obsession in our field, IMO, and I think we've reaped the whirlwind for it already. It's time for a more holistic outlook.

I agree that most of the time you should trade performance for coding faster, since fast computers often allows you to release a working solution in much less time.

Meanwhile, there is also this tendency of software getting slower, and this other tendency of code getting trashed because it was written as a short term solution.

C++ is designed for high quality, meaning taking more time to write a better solution. It's more thought towards industrial long term quality than market quality. I guess a bad analogy would be engineering versus maintenance. There is often much less engineering to do than maintenance.

C++ is designed for high quality, meaning taking more time to write a better solution.

I just don't believe that at all, performance and backwards compatibility has been trumping quality throughout it's development.

As example, I never had any issue with bounds checking being enabled in all languages I used through my career.

Even in C++, I always had bound checking on my own classes and always make use of the validation flags in VC++.

It never mattered to the type of applications I was involved with.

I spent some time working on HFT systems. These things needed to achieve end-to-end timings (from a tick being DMAed into our memory to placing an order) around xx microseconds at the 99th percentile. The bulk of the code was written in a language that forced us to have bounds checking everywhere, and that was totally fine.

I'd assume most array boundary checks can be optimized away by a good compiler anyhow, assuming the array semantics allow that in the language in question.

The cost of bounds checking is very manageable with modern CPUs and compilers. (I guess the bounds checks execute in parallel with the cache lookup into the array).

Firefox now uses it in release builds (for vector-like objects) for security reasons, and IIRC there was no real performance impact.

Even back in the Algol 60 days, it was manageable.

"Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."

-- C. A. R. Hoare, Turing award lecture in 1980, http://cacm.acm.org/magazines/1981/2/10949-the-emperors-old-...

> a fundamental 1.2x performance penalty on Rust's part

We don't believe such a thing exists.

That's a good point, and I didn't mean to parrot FUD by implying that that multiple definitely exists; more that, even if die-hard C++ boosters are right about it existing, it's still not the ace in the hole it's made out to be given all of the other factors that likely overwhelm it.

Reply on news.ycombinator.com