381–390 of 606 posts
Earlier quoted context omitted.
No offense, but I haven’t heard if people wasting days in semicolons outside of memes and really junior developers. What was the issue?
In real-time systems with millions of lines of code, no debugging capabilities outside of logs, and user misuse use cases, you'd be surprised what can lurk beneath.
Earlier quoted context omitted.
Oh absolutely! Here’s an example from 2019: https://www.cve.org/CVERecord?id=CVE-2019-15900 “An issue was discovered in slicer69 doas before 6.2 on certain platforms other than OpenBSD. On platforms without strtonum(3), sscanf was used without checking for error cases. Instead, the uninitialized variable errstr was checked and in some cases returned success even if sscanf failed. The result was that, instead of repor…
The problem here is that that implementation was written in plain old C and is super unsafe, and is NOT C++. I don't know why C keeps getting confused with C++ because the two are basically totally different now.
char buf[10];
std::cin >> buf;
std::cout Sure, you can write secure code in C++. You can write secure code in C too, even if that language is “super unsafe”. But neither language will stop you from writing insecure code either.
Earlier quoted context omitted.
Programming languages are tools for a job. As the saying goes, a bad workman blames his tools. It's not worth taking anyone who blames defects on a programming language too seriously, whether it's Google or not. Modern C++ has many memory safety features. If a company has learned that its people fail to use them, then bad for them. Of course, there are languages that abstract memory safety to the point that they elim…
> We should not bury C++ prematurely before answering the question - "what else is as fast and efficient as to replace it for OOP?" We have an answer: Rust. It's no longer premature, bury it.
See how many reference types are there, how async is handled and the underspecified unsafe semantic.
For higher level tasks, I prefer a language with GC like go or java. Rust can work with references counting, but it don’t mix well with the larger ecosystem. For lower level task, the underspecified unsafe model make it worse than C aliasing problem
Earlier quoted context omitted.
>The reality is which almost everyone can see is that memory safe languages are pretty much always what you want to be using for new code. Not everybody is writing security-critical code. For some things productivity and time-to-market is more important and security is not enough of a concern to justify dealing with a language with horrible compile times and a self-righteous, dogmatic community.
We probably need to bring in some kind of criminal liability for the companies that only cared about time to market and put their users at risk. After memory safe languages become a bit more battle tested, C/++ needs to be regulated like asbestos.
Earlier quoted context omitted.
> We should not bury C++ prematurely before answering the question - "what else is as fast and efficient as to replace it for OOP?" We have an answer: Rust. It's no longer premature, bury it.
Rust is over engineered in some area, immature in other. See how many reference types are there, how async is handled and the underspecified unsafe semantic. For higher level tasks, I prefer a language with GC like go or java. Rust can work with references counting, but it don’t mix well with the larger ecosystem. For lower level task, the underspecified unsafe model make it worse than C aliasing problem
2, & and &mut. What else?
Earlier quoted context omitted.
Cool kids and students move to Rust, C++ doesn’t have influx of new developers hence more demand for existing C++ developers.
We haven't seen the same thing for PHP and other obsolete languages. Cleanup janny work isn't as respected or well paid as building cutting edge new things in modern tools.
Earlier quoted context omitted.
> Utterly unthinkable, isn't it? No. Ignaz Semmelweis faced it in the 1800s for daring to suggest (what we know know as germs) made people sick and hand washing could drastically reduce medical complications. He was able to prove it too. By the end was locked up in an asylum for his ‘crimes’. Want more recent? How many stories have you heard of instruments or gauze or whatever left in surgical patients? Of operating…
Semmelweis is ancient history. He was active at a time when regulations and "best practices" simply weren't a thing anywhere. Surgeons resisting checklists is new to me. Do you have a reference other than a TV show? My understanding until now was that checklists are extensively used in medicine.
> Despite all the evidence, Gawande admits that even he was skeptical that using a checklist in everyday practice would help to save the lives of his patients.
> "I didn't expect it," Gawande says with a chuckle. "It's massively improved the kind of results that I'm getting. When we implemented this checklist in eight other hospitals, I started using it because I didn't want to be a hypocrite. But hey, I'm at Harvard, did I need a checklist? No."
https://www.npr.org/2010/01/05/122226184/atul-gawandes-check...
Not sure if this supports the reluctance idea since it says 93% use checklists, but most surgeons don't think it improves safety.
> Of the 353 survey respondents, 93.6% use SSCs and 62.6% would want one used in their own child’s operation, but only 54.7% felt that checklists improve patient safety.
Earlier quoted context omitted.
C-nile developers have been making incorrect arguments for a while now. The reality is which almost everyone can see is that memory safe languages are pretty much always what you want to be using for new code. OS and security sensitive components are the prime targets for rewrites in more secure languages. Now Google has put this to the test and has the data to prove it. We should not allow the worlds technology secu…
>The reality is which almost everyone can see is that memory safe languages are pretty much always what you want to be using for new code. Not everybody is writing security-critical code. For some things productivity and time-to-market is more important and security is not enough of a concern to justify dealing with a language with horrible compile times and a self-righteous, dogmatic community.
Earlier quoted context omitted.
Programming languages are tools for a job. As the saying goes, a bad workman blames his tools. It's not worth taking anyone who blames defects on a programming language too seriously, whether it's Google or not. Modern C++ has many memory safety features. If a company has learned that its people fail to use them, then bad for them. Of course, there are languages that abstract memory safety to the point that they elim…
> We should not bury C++ prematurely before answering the question - "what else is as fast and efficient as to replace it for OOP?" We have an answer: Rust. It's no longer premature, bury it.
I would love to know about any projects that do OOP well in Rust.
Earlier quoted context omitted.
Seems like drawing too many conclusions from evidence while arguing against a straw man? Defenders of C might note that Android is java and IOS is not and compare the security of those two systems and say clearly memory-safe is focusing on the wrong thing. This is equally true but no more valid an argument. The one that really bothers me in all these language-booster discussions (that we should and need to have) is t…
> We have no ssl library written in a memory-safe, functional language that has been proven correct that has dominated the space. Heartbleed wasn't yesterday. Heartbleed didn't affect https://hackage.haskell.org/package/tls even though it isn't formally verified.
And I don't know about "used at scale" but we use it in production for Pernosco.