gjajric

You have made two major mistakes, which is common among Rust proponents, and which is disconcerting, because some of those mistakes can help lead to memory safety bugs in real life Rust programs. And thus, ironically, by Rust proponents spreading and propagating those mistakes and misconceptions about Rust, Rust developers mislearn aspects, that then in turn make Rust less safe and secure than it otherwise would have been.

1: The portions of the code that have to be checked of unsafe blocks are not limited to just those blocks. In fact, in some cases, the whole module that tiny unsafe blocks resides in have to be checked. The Rustonomicon makes this clear. Did you read and understand the Rustonomicon?

2: Unsafe Rust is significantly harder than C and C++. This is extra unfortunate for the cases where Rust is used for the more difficult code, like some performance-oriented code, compounding the difficulty of the code. Unsafe Rust is sometimes used for the sake of performance as well. Large parts of the Rust community and several blog posts agree with this. Rust proponents, conversely, often try to argue the opposite, thus lulling Rust developers into believing that unsafe Rust is fine, and thus ironically making unsafe Rust less safe and secure.

Maybe Rust proponents should spend more time on making unsafe Rust easier and more ergonomic, instead of effectively undermining safety and security. Unless the strategy is to trick as many other people as possible into using Rust, and then hope those people fix the issues for you, a common strategy normally used for some open source projects, not languages.

Swift does not seem suitable for OS development, at least not as much as C or C++.[0] Swift handles by default a lot of memory by using reference counting, as I understand it, which is not always suitable for OS development.

[0]: Rust, while no longer officially experimental in the Linux kernel, does not yet have major OSs written purely in it.

Didn't save Cloudflare. Memory safety is necessary, and memory safety guard rails can be helpful depending on what the guard rails cost in different ways, but memory safety is in no way, shape or form sufficient.

I have heard different arguments, such as https://zackoverflow.dev/writing/unsafe-rust-vs-zig/ .

According to the strange data at https://survey.stackoverflow.co/2025/technology#most-popular... , 44.6% have responded positively to that question regarding C++. But there may be some issues, for the question involves two check boxes, yet there is only one statistic.

Steve Klabnik?

Either way, that survey (you could have linked to it) has some issues.

https://survey.stackoverflow.co/2025/technology#most-popular...

Select the "Learning to Code" tab.

> Which programming, scripting, and markup languages have you done extensive development work in over the past year, and which do you want to work in over the next year? (If you both worked with the language and want to continue to do so, please check both boxes in that row.)

It describes two check marks, yet only has a single statistic for each language. Did StackOverflow mess up the question or data?

The data also looks suspicious. Is it really the case that 44.6% of developers learning to code have worked with or want to work with C++?