I wonder how long the same story will repeat before the balance shifts in favor of just rewriting in more modern languages. It's expensive work with a long ROI, but sounds like a lot of these are in foundational libraries that you want to be robust in the long run.
This is especially applicable for various parsers that are typically self-contained code that is not performance critical but very prone to bugs with nasty consequences like the article demonstrated again.
[1] - https://hacks.mozilla.org/2021/12/webassembly-and-back-again...
Haskell's Software-Transactional-Memory (and general focus on immutability-by-default) are another interesting approach towards the same goal.
Software Transactional Memory (STM) is perhaps much easier to get started with than Rust's model. (Though the same can not be said for the rest of Haskell.) The failure model with STM is that your stuff runs slow, if you don't know what you are doing.
Iterators require at least two mutable references or mixing mutable and non-mutable references. Move-only types require a lot of boiler plate and accidental usage of moved thing is not detected by the compiler. Using std::variant feels like a trolling from the language designers who refused to provide proper type-safe unions into the language.
And, alas, deliberate trolling would be preferable to reality.
Deliberate trolling would indicate a conscious design. C++ accumulated cruft over the years in what looks like brownian motion in retrospect, and almost never shed any.
For OS and browsers though, I agree completely if infrastructure as long as its not always connected to the open internet, it doesn't seem to be much of a threat, and even though I don't care about memory safety, the performance of rust tools impresses me! I wish people talked about performance of rust more than its memory safety, I don't care as much about that, but everything being faster? Who wouldn't want that? I made this thread a few days ago. https://news.ycombinator.com/item?id=29456115
See eg https://hacks.mozilla.org/2019/02/rewriting-a-browser-compon...
More pithy: Hanlon's razor says 'never attribute to malice that which is adequately explained by stupidity.', but the reverse is also true: enough stupidity or just randomness can look like malice.
The threat of most security issues is vastly overblown, spectre and meltdown don't exist in the wild, but they crippled all CPUs just in case. Security at what cost? I disabled it, I have no need to make my computer slower for a virus that will never affect me, I "wear" an updated browser. ;)
Nothing new should be written in these unsafe languages.
If Spartans were alive they would be using C or C++.
I do think Apple is honestly committed to Swift over the long term, but it takes loads of time and care to replace the foundations of a building that's in daily use.
They might be committed to it, but I'm doubtful that it's at all possible to write e.g. parts of the kernel in it. And maybe, just maybe, they should direct all their efforts toward rewriting the OS in a safer language instead of making their UIs uglier with nonsensical paddings and messy-looking icons that pretend that there's no pixel grid.
But it would be more interesting to see the parts that deal with untrusted data (file format parsers, protocol handlers) rewritten in Swift.
(There were absolutely spaces where robustness and safety were the priority, but those weren't consumer, and their cost reflected it.)
Even today, I'm not sure we have the engineering margin spend on such efforts (time-to-market is still the priority), though I think the pressure is slowly increasing to do it (again, in consumer spaces, which macOS definitely is).
No one would enjoy paying for a fridge that leaks water, why should they do the same for software.
Bad programming shops taught them that way, that is why.
Most of these programming languages when they were created did not have online connectivity or hackers as a threat. It would be ridiculous to expect them to protect against a threat that didn't exist like calling Japanese idiots for not making nuclear defenses and their bad teachers are the reason. In embedded hardware I still don't see the benefit for memory safety.
In fact it was one of the sales pitch for Burroughs (1961), still being sold by Unisys, which not surprisingly keeps using its safety over classical POSIX as sales pitch.
By the forces of the market, POSIX won because it had more useful features. Personal computers where you were expected to load software yourself and were not connected to any threats? I do not see any reason for me to care about that even today, and its not because programmers had bad habits, they made reasonable tradeoffs, making worst performing software for nonexistent threats of that time is not teaching them bad programming, over engineering for nonexistent threats is bad programming. In non networked devices, I still see no benefit.
It is like 1 euro shops, quality is not what customers are looking for.
Had UNIX been sold like every other OS from the same decade, and it would have been a footnote on the history of OS.
When one is thirsty any liquid goes down regardless of the taste.
If anything, safety considerations in embedded devices are even more important than elsewhere, if only for the fact that those devices typically don't get patched. It has to work right the first time. F*cking this up can have dire consequences, depending on what the device is doing.
There's no law against licensing bad fridges with the explicit warning that they might leak, is there?
Many people choose to go with fridges that are higher quality than the absolute minimum. Some people also choose to pay for extended warranties.
Many other people choose less reliable options, because they have other preferences.
This choice on offer is a good thing.
Why do you want to ban this choice?
Would open-source be effectively outlawed in your favourite world?
Whatever one does to themselves on their own place is their own thing, if they happen to land at the hospital due to food poisoning caused by bad refrigeration.
In any case, the fridge was only one example among thousands.
See, you are suggesting here that customers don't want bad fridge, so they don't buy bad fridges. The problem solves itself.
Why not give customers of software the same responsibility and maturity?
> No one would enjoy paying for a fridge that leaks water,..
For fridge people pay serious money. For software people dig deep in their pocket and then come back with "Fuck it , I am gonna use open source stuff"
I guess what really made it a niche language was the cost of compilers. DoD vendors in eighties already learned how to milk their customer.
People by-and-large _choose_ to license software where the license contract denies liability.
You are free to offer 'proper' liability, and try to charge enough extra for it to make up for your extra costs.
(Or do you want to forbid certain kinds of contracts, so that your preferred kind of contract 'wins' because the competition is banned?)
Do keep in mind that some software does come with liability, and things that are a bit like liability. The latter category is eg when you sell both software and a support contract, and your support people have to work harder when stuff goes wrong.
In fact, in many jurisdictions there are laws against (or, more to the point, denying any effect to) the waivers of liability much software comes with.
It's too early to tell -it dropped last friday - but it will probably be marked as one of the most egregious vulnerability to date due to the sheer omnipresence of Log4j in production java's code and the simplicity of its exploitation. We are talking Heartbleed/EternalBlue/Struts2 vulnerability level here.
The difference of ROI of memory-unsafe/memory-managed is not so evident. Usually memory-managed languages have fewer bugs, but those tend to be massively impactful
The log4j bug fits in the "other" category.
Also, it's a fallacy to believe that memory-safe languages aren't that much better because their bugs are worse. All languages can have the worse bugs, it's just that memory-safe languages solved the easier type of bugs, so there isn't as much of them to bring the average down.
It's like thinking that flying is riskier than driving, because plane crashes are so devastating. Driving kills more people overall, but they're spread across more, smaller events, so we're not as aware of them.
A rewrite will likely introduce plenty of CVEs that weren't present in the original code -- possibly more than are fixed, for many years to come.