News for hackers. Stuff that matters.
Re:Concurrency in Rust by quotemstr on Sunday March 27, 2016 @04:25PM (#11371397)
> for example, Google!

Google's C++ coding standards have done tremendous harm to the C++ community by perpetuating obsolete programming practices like two-phase initialization and lossy error reporting. Google's C++ standards also teach people that it's okay to use the STL and not worry about allocation failure, which hurts program robustness generally.

I'm not the only one who thinks so: see https://www.linkedin.com/pulse/20140503193653-3046051-why-go...

My C++ code is exceptional, modern, and robust, and anyone using -fno-exceptions can go fly a kite.

Re:Concurrency in Rust by pcwalton on Sunday March 27, 2016 @04:58PM (#11371538)
I think it's hard to argue that Google is in the wrong by not wanting to rely on std::bad_alloc for dealing with OOM.

> Google's C++ standards also teach people that it's okay to use the STL and not worry about allocation failure, which hurts program robustness generally.

Actually, I think making std::bad_alloc call std::terminate improves program robustness by a lot over trying to gracefully recover from all allocation failure. Certainly it reduces security vulnerabilities.

Re:Concurrency in Rust by quotemstr on Sunday March 27, 2016 @05:43PM (#11371694)
> Certainly it reduces security vulnerabilities.

So does the power button. You can't get away with justifying breaking arbitrary functionality in the name of security.