There will always be bugs in software and hardware. This being said, our civilization is litterally built on C/C++ systems (Linux, Windows, Databases, iOS, Android) from people who deal with very sharp knives. Much of our crypto infrastructure is written in assembly.
Conversation
Replying to
That infrastructure will always collapse and that much of it is old is no excuse for not following modern construction norms, question is if SW can self-regulate or regulators need to step in. Some low-level primitives will always exist, asm in crypto to prevent timing attacks...
2
1
1
Replying to
I would love for something like Swift/Rust to replace C/C++ in system engineering but, for the time being, our software stack needs C/C++. And don't sell C/C++ short: we have amazing tools to alleviate their failings.
cc
2
2
Assuming one language does take the throne from C/C++, even the ultimate winner may have a significantly smaller niche than C/C++ ever had - for a large part of their life they were used as general purpose languages rather than just "system" or "perf matters" languages.
2
1
Agreed.
Hopefully we'll be left with a systems language focused on system stuff. My bet is on Rust or a future entrant. Swift is an Apple thing and Apple things usually stay Apple things. Of course, if Apple takes over the world, we'll all be writing OSes in Swift I guess.
3
1
it has to be Rust or something new, unless I'm wrong about Swift or unless Swift evolves quite a bit
3
2
Swift has had some plans for ownership tracking and better control of stack use, like Rust... but they seem to be focusing a lot of resources to fight garbage-collected languages for the web app space
Quote Tweet
After tinkering for well over a year, we are close to dumping Swift on the server, and rewriting our app in something else. Memory keeps leaking at alarming rate (~1 GB+/day). Combination of Vapor 3, SwiftNIO, & Swift Foundation for Linux doesn’t seem production ready. 
Show this thread
2
1
It's much different as a core part of the language with the rest of the language and library features built around it. It can only ever be extremely second class in Swift without massive backwards incompatible changes and a shift in focus which I don't think is at all desirable.
1
1
It's perfectly fine that Swift has a different focus. I don't think features like sophisticated safe lightweight references fit into it at this point. It could gain features for ownership, limited lightweight references and control over memory but it'd be a much different thing.
Here is Swift's ownership manifesto in case someone is interested in what they're planning github.com/apple/swift/bl
1