> The title of this blog might sound a bit dramatic, but everyone has different definitions and understandings of "safety."
Still in Rust community "safety" is used in a very specific understanding, so I don't think it is correct to use any definition you like while speaking about Rust. Or at least, the article should start with your specific definition of safety/unsafety.
I don't want to reject the premise of the article, that this kind of safety is very important, but for Rust unsafety without using "unsafe" is much more important that an OS dying from leaked connections. I have read through the article looking for rust's kind of unsafety and I was found that I was tricked. It is very frustrating, it looks to me as a lie with some lame excuses afterwards.
I apologize for not using a good title, but I think the issues I listed (especially my argument that we should break issues down to bugs in runtime and the limitations of Rust abstractions) are worth discussing, even if there are many people who argue otherwise
Don't be hard on yourself. I recall times when Rustaceans eagerly marketed "memory safety" to mean "safety" in general. Sometimes even extending "safety" to mean "bug free".
I chalk up the confusion to true believers playing the motte-and-bailey game. When the marketing meaning feels good, they use it all over the place. Then, when the substance doesn't live up to the hype, the fans retreat to the technical definition. This is not a new phenomena: https://news.ycombinator.com/item?id=41994254
Agreed, though a better title would probably not use the term "safe" unqualified (e.g. "Async rust with io_uring leaks resources (and risks corrupting program state").
So in this case it is still a form of safety that’s well-defined in rust: cancel safety. The io-uring library doesn’t have the same cancel safety guarantees that everyone is used to in epoll libraries. In Tokio, the cancel safety of `accept` is well documented even though it works the way you’d expect, but in monoio, it’s literally just documented as `Accept` with no mention of the cancel safety issues when using that function.
I agree with these points but as someone that has been using rust for a long time now, this “you can’t do that, it is not good” attitude got very stale by now. Not saying it is bad to say these stuff, anyone should do what they want in the end including saying this. But just sad that this is very common in Rust discussions and it gives a bad taste to me
I can agree that rustaceans are tiring sometimes, for example, their rejection of unsafe code goes too far. I believe, it is better to learn how to wield this beast and learn how to use it to make code better. But I keep my thoughts to myself, because rustaceans will jump to explain me that I conform to the opinion of the majority and to avoid unsafe at all costs. Yes, it is not a good for the community.
But this specific case is not like that, my issue with the headline that it is a clickbait, and the article is written in a way, that you can't detect it early.
> anyone should do what they want in the end including saying this
I disagree. Any community, any group, any society has some rules, that exist for the good of the group. One of the most frequent rules is "do not lie". The headline de facto lies about the content of the article. I was mislead by it, and I'd bet that the most of rustaceans were misled also. Moreover, it seems to me, that it was a conscious manipulation by the author. Manipulation is also for the most groups of people is a bad thing, even if it doesn't rely on lies. It is bad not just for rustaceans. Here on HN you can see complaints about clickbaity titles very often, people are really annoyed by them. I'm relatively tolerant to clickbaits, but this was too much.
Interesting. I would have thought that leak-free is part of the premise, since you can very well right C or C++ with a guarantee of no use after free at least, assuming you don't care about memory leaks.
The difference is that memory safety of any kind (including leaking everything) in C/C++ requires discipline, whereas in Rust the compiler is what prevents it. And yes, leaking is not part of that guarantee, because leaks cannot cause corruption or undefined behavior.
With that said, while Rust does not guarantee it, it does have much better automatic memory cleanup compared to C++, because every value has only one owner, and the owner automatically drops/destructs it at the end of its scope.
Getting leaks is possible to do with things like Box::leak, or ref-count cycles, but in practice it tends to be explicit, rather than the programmer forgetting to do something.
Still in Rust community "safety" is used in a very specific understanding, so I don't think it is correct to use any definition you like while speaking about Rust. Or at least, the article should start with your specific definition of safety/unsafety.
I don't want to reject the premise of the article, that this kind of safety is very important, but for Rust unsafety without using "unsafe" is much more important that an OS dying from leaked connections. I have read through the article looking for rust's kind of unsafety and I was found that I was tricked. It is very frustrating, it looks to me as a lie with some lame excuses afterwards.