Percentages add up to 100. As segfaults and exploits due to buffer overruns or use-after-frees decrease, the proportion of bugs that come down to logic errors will increase.
If the way you achieved memory safety (or performance) means your code is so ceremony-heavy that it starts to impact correctness, because you can't so easily see what it is actually trying to _do_, this is unfortunate.
There's this increasing tendency to talk about memory safety as if, because it's the most pressing problem _right now_, solving it means you've won the battle. But that's not the end goal… it's the start. Literally the least you can do.
Whenever I read the headline “House Republicans Brace for Drawn-Out Speaker Fight” I like to imagine them having a massive argument about whether or not you can hear the difference a supertweeter makes.
I’ve wandered into an alternate universe where I'm dealing with some people who seem only capable of communicating via phone, and its murder. I email them saying we should schedule a time to talk, and they call me to try and arrange that time. I cannot answer so I email them and later that day they call me again. Send help.
And some bonus #swift content: the “Build robust and resumable file transfers” talk includes a section on building the server side of resumable uploads using SwiftNIO, complete with sample code.
In What's new in Swift I mention the performance improvements from the new Swift implementation of Foundation. Performance came up a lot when we first put the open source package live, but wasn't easy to talk about until the new OS betas were available.
One common trope at the time was “it isn't faster than using Objective-C, this is just to reduce Swift bridging costs” and while that's true, it's important to note Swift is _just plain faster_, as seen even when calling into it from ObjC.
US default has some fun Y2K-ish consequences, since plenty of software just doesn’t account for the possibility of treasuries not just becoming inert the day after they mature.