I feel like he is missing the boat here. C++ is on a path to dying as a language because of a lack of safety features, and he’s talking about zero cost abstractions. Exceptions cause massive compiler issues and are hardly zero cost anyway, I don’t know how he can compare them at all to std::expected. Also anyone who has worked in an exception heavy codebase can attest to the fact that they do not lead to simpler code.
I have worked with C++ almost every day for a decade now, and I’ll be sad to see it go. This is not what the thought leaders should be focusing on at all. If you’re unhappy with std:: expected just don’t use it? Why can’t we focus on fixing the thousands of security vulnerabilities that cause real harm and money and endless developer time to try to work around.
zevets 10 hours ago [-]
I want to use std::expected because I want clear, explicit error handling, not performance.
There is a time and place for performance optimized code - but usually where the hot loop is well known, and its a tiny minority of the program.
on_the_train 7 hours ago [-]
All this recent safety talk is so strange to me, also a decade-long cpp dev. I read all this drama and worries, but that never relates to worries I experienced with the language. I've only ever seen safety issues with absurdly bad and old code that would never go past static analysis anyways, let alone a code review.
Real issues for my peers and myself are things like the thirst for reflections, the thirst for throwing out old garbage. Certain gripes with language details like initialization, the way a few things have been implemented etc.
I genuinely feel puzzled by the topics of all these cpp posts. Is everyone coding ultra low level with tooling from 1999?
pjmlp 4 hours ago [-]
Unit tests and code review are the exception, not the rule.
One thing that has changed is that nowadays software is everywhere, cyberattacks as well, with corporations and goverments putting numbers into the dollars that get burned in developer salaries, fixing CVEs, rolling out updates, downtimes caused by bug fixes, insurance claims, insurance premiums, lawsuits, malfunction software which consultancies have to fix free of charge,.....
majikaja 6 hours ago [-]
Maybe the focus is cheaper junior devs?
jitl 8 hours ago [-]
Well theres been like 3 C++ drama posts in the last 2 weeks detailing that the standards committee is definitely not heading towards a comprehensive safety solution. They have “profiles” which is a nothingburger, and they’re sticking to it.
drewcoo 10 hours ago [-]
I agree that we need better performance testing but I tend to see it as a top-down or an operations-in problem. Performance work from the bottom up, from low-level code constructs seems like the kind of work I've seen XKCD or even Dilbert cartoons about. That is the path of premature optimization and bike shedding.
I'd love to see the industry do some kind of compositional service-level perf work. I'd love something like a contract testing view or perf, so that I can see how changes in a single part of the system will affect over-all SLAs. The tooling we have now seems to be of the form where if we want system perf, we need the big, expensive, kludgy full systems running for perf tests. And that kind of thing slows down dev velocity.
I hope someone from SmartBear reads this is knows the right tech to acquire to accomplish this (give me Pact/PactFlow but for perf!).
9 hours ago [-]
Rendered at 14:32:28 GMT+0000 (UTC) with Wasmer Edge.
I have worked with C++ almost every day for a decade now, and I’ll be sad to see it go. This is not what the thought leaders should be focusing on at all. If you’re unhappy with std:: expected just don’t use it? Why can’t we focus on fixing the thousands of security vulnerabilities that cause real harm and money and endless developer time to try to work around.
There is a time and place for performance optimized code - but usually where the hot loop is well known, and its a tiny minority of the program.
Real issues for my peers and myself are things like the thirst for reflections, the thirst for throwing out old garbage. Certain gripes with language details like initialization, the way a few things have been implemented etc.
I genuinely feel puzzled by the topics of all these cpp posts. Is everyone coding ultra low level with tooling from 1999?
One thing that has changed is that nowadays software is everywhere, cyberattacks as well, with corporations and goverments putting numbers into the dollars that get burned in developer salaries, fixing CVEs, rolling out updates, downtimes caused by bug fixes, insurance claims, insurance premiums, lawsuits, malfunction software which consultancies have to fix free of charge,.....
I'd love to see the industry do some kind of compositional service-level perf work. I'd love something like a contract testing view or perf, so that I can see how changes in a single part of the system will affect over-all SLAs. The tooling we have now seems to be of the form where if we want system perf, we need the big, expensive, kludgy full systems running for perf tests. And that kind of thing slows down dev velocity.
I hope someone from SmartBear reads this is knows the right tech to acquire to accomplish this (give me Pact/PactFlow but for perf!).