Excellent piece from Herb Sutter once again. This is a very well balanced view about language safety and how far C++ could go in this direction. This is a nice call to action, would like to see quite some of that happen.
Check out the docs branch for detailed explanations. This exhibits a loop hole in the Rust compiler allowing to break lifetime inference... and from there all the usual guarantees go through the window.
It's here to sell something. That said it does a good job explaining the Erlang model and its "let it crash" approach to failures. Also highlights the obvious limitations.
Very interesting contribution to the FreeBSD hackers mailing list. Gives quite a good background about Rust, C++ and safety. Debunks a few claims you can easily hear in many places as if they were common knowledge.
The results of this investigation are actually super scary... Even if you don't own one, those are in our streets. In any case it is a clear statement that you can't and shall not run an automotive company like a startup...
Very interesting musing about undefined behaviors and language constraints. This is a bit Rust focused for obvious reasons but is also looking at what other languages have been doing.
This is an easy mistake to make. I'd say the API isn't helping there either, there's an improvement to find in Cap'n'proto to make it safer.
Nice trick to get the pressure off the team while it looks for a proper solution.
How the medical sector is struggling with badly designed software. Also important to note how security is just getting in the way of nurses and doctors jobs.
Nice approach to also hunt for memory safety issues while software is in production.
This is a big deal for the places where Rust could shine.
A good reminder on how the "five why" are just a starting pont. For proper investigation and risk management you need to go deeper.
This is a neat example of what programming languages could check at compile time. This clearly brings way more safety when you get such contract validation at build time.
Long but fascinating article on a blend of guidelines which could be statically checked to enforce a memory-safe subset of C++.
Kind of sad to see asserts misused so much in the Python community. Still that's a good lesson for everyone: when using an assert, expect it won't get executed when in production.
Indeed, the story of integrating C and C++ with Rust isn't a simple one right now. It might introduce larger attack surfaces. Some improvements are proposed in this paper.
Interesting take... Is it really practical? Until which size is it viable? What are we loosing by aggregating? Also makes me wonder about alert fatigue... It clearly raises extra questions.
There are really many initiatives to make C and C++ safer lately. I wonder which one will see adoption and what will make its way to the standards.
People tend to be fixated on the "unsafe" keyword and assuming not using it will make their code devoid of memory safety bugs. Well, it's a bit more subtle than this. It helps you know where such bugs can hide but it can't completely prevent them all the way down the stack.
Interesting approach. There's still a lot we can achieve with static analysis in those good old languages.