We haven't found that person yet, but if we stop believing that person exists, then why are we still writing in these languages?
All they'd have to do is provide us a stable, secure foundation and a hypervisor that can run legacy OS's. Oh, and reimplement/replace the tens of thousands of API's provided by Windows/UNIX/Linux which are in use by millions of programmers everyday.
Also they'd need to be able to support all those other secure languages that have been written in C/C++ over the years. I guess they will be able to rewrite those as well in short order on top of their new "secure" foundation.
I'm sure it will happen any minute now.
JavaScript developers have told me on a few occasions that TypeScript is unnecessary, they can just write good JS and they don't need types! And it doesn't even catch every bug, so why bother?
I think I'm just tired of being told that while I can't write safe C, it's because I'm not smart enough (which may be true, I guess!), but also that the reason everyone else can't write safe C is because they, too, happen to also be not smart enough: https://news.ycombinator.com/item?id=23289693
> I design high-scale database kernels, large code bases, written in modern C++. I can’t remember the last time we had a memory safety issue. It isn’t as though we don’t have plenty of bugs during development, just not those kinds of bugs. Competent idiomatic code simply doesn’t leave much room for those kinds of bugs to occur. If you “constantly struggle with memory safety issues”, you are doing something fundamentally wrong. That’s not something you can blame on the language.
>
> I am always baffled by the people that supposedly write modern C++ professionally and constantly have memory safety issues. Most serious projects won’t hire you if you aren’t capable of writing memory safe code in your sleep, it is a basic skill.
The problem is, to be taken seriously, eventually they will need to demonstrate that they can solve the problem, rather than just talk about it.
I don't dispute the need for OS/systems development to move towards more secure languages, that much is clear. It's just none of the "visionaries" that talk about it so much have a clear roadmap that wouldn't put millions of working programmers out of jobs, let alone much in the way of working prototype code.
As such, it seems to be somewhat of a programming language enthusiasts pipe dream. 99.5% of people who seems to working on hobby OS projects choose C/C++, because that's where most of the accessible prior art is, and because it gives them a snowballs chance in hell of being able to port of wide range of pre-existing software and applications to their platform.
Rust has a bunch of hobby OS projects, and a very serious OS project called Redox OS[0]. Redox has a libc that's complete enough to allow it to run bash and other existing programs. It has a complete graphics stack, including its own compositor and UI toolkit.
Meanwhile, Microsoft is actively testing Rust as a language, both for new components and rewriting old code that would traditionally be written in C/C++[1]. They're doing this because memory safety bugs account for 70% of their critical bugs[2]. This is a major player in the industry, actively looking at a memory-safe language because they find C or C++ to be inadequate. If that's not validation enough, I don't know what is.
[0]: https://www.redox-os.org/
[1]: https://msrc-blog.microsoft.com/2019/11/07/using-rust-in-win...
[2]: https://www.zdnet.com/article/microsoft-70-percent-of-all-se...
Everybody who reads HN regularly with an interest in OS design and security and application security has heard of [0], and [2]. [1] simply says that Microsoft is "exploring" Rust, for an "experimental" rewrite of a low level component. That's it. No shipping code yet. I agree its a good step forward, but let's not overstate the impact just yet. If you consider that "validation enough", that's fine, but many others will disagree at this early stage, especially in context of displacing an entire ecosystem of C/C++ based systems and languages.
Lastly, Redox is a great example of what I'm talking about, people actually putting their money where their mouth is, and I think it's great to see. It also has 0% adoption outside of a small group of developers right now, and clearly has a long way to go. However by shipping a libc in order to support C programs, they risk exposing application security issues in exactly the same manner as the type of systems they are trying to replace (surely), unless they are prepared to develop additional proven mitigations.
Kudos to them for trying, but it remains to be seen whether they even get enough momentum to threaten, yet alone displace the incumbents. Surely history has shown that those platforms with the "killer applications" are those most likely to succeed, and that many elegant and better designed systems than UNIX/Windows have lost out to pragmatism on the part of customers/consumers.
They can step forward now and deliver stuff.
Of course it will not be quick. But I don't see the point of ridiculing that effort either. It's not like Linux took over from Unix immediately either (even though the interface then was tiny in comparison).
Linux grew rapidly in part because there was already a huge amount of C programmers on the Internet as well as UNIX admins, and Linux was reimplementing a fairly well known set of API's. Rust/Redox don't have quite the same head start. I wish them every success though.