It's definitely a trade off. But Sutter is extremely selective in the analysis put forward on that trade off. Selective enough that I find the wording pretty misleading overall. And that particular paragraph is still a non-sequitur. The language used is pretty clearly "because foo, bar happened." Emphasis mine:
> However, this same feature also requires Rust programs to use unsafe code more often to represent common data structures that do not require unsafe code to represent in other MSLs such as C# or Java, and so 30% to 50% of Rust crates use unsafe code, compared for example to 25% of Java libraries.
This isn't a carefully considered statement about trade offs. This is sloppy reasoning. For example, if the reality were that 99% of that `unsafe` code were just FFI interactions with programming languages that are memory unsafe by default, then that would kind of undercut the entire point here. That is, it wouldn't really be Rust's fault. It would be the fact that we've lived in a memory unsafe hegemony in systems languages for the last several decades. That's just reality.
Of course, I'm sure it isn't 99%. But I'm also sure it isn't 1% either. The reality is so much more interesting than "30%-50% of all crates have `unsafe` in them." And that reality could very well undercut the entire point Sutter is making in this part of the article.
What's the overall steelman here? Something like, "Rust isn't a silver bullet. Let's make a subset of a superset of C++ that's safe." Okay, cool. Sounds great and the attempt at making C++ without breaking existing users certainly seems like an uncontroversially good thing to try. I don't really have any response to that.
I don't need a "lense of negativity" to criticize the details of Sutter's argument. This part of the article in particular would be a lot weaker overall if Sutter presented the reality than some sloppy non-sequitur. And that actually matters for his argument because it cuts to the heart of just how big of a trade-off Rust really is. If it isn't as big as he seems to be suggesting, then Rust's value proposition gets stronger. It's a critical flaw in his reasoning.
Steelmanning is great and we should try to do that. But I don't actually see a stronger version of Sutter's argument here. It's not just a phrasing issue, although the phrasing is certainly what jumped out to me. And I could just as easily say that the problem with Sutter's article is that he isn't doing a very good job of steelmanning the case for Rust. Whoop de do.
> However, this same feature also requires Rust programs to use unsafe code more often to represent common data structures that do not require unsafe code to represent in other MSLs such as C# or Java, and so 30% to 50% of Rust crates use unsafe code, compared for example to 25% of Java libraries.
This isn't a carefully considered statement about trade offs. This is sloppy reasoning. For example, if the reality were that 99% of that `unsafe` code were just FFI interactions with programming languages that are memory unsafe by default, then that would kind of undercut the entire point here. That is, it wouldn't really be Rust's fault. It would be the fact that we've lived in a memory unsafe hegemony in systems languages for the last several decades. That's just reality.
Of course, I'm sure it isn't 99%. But I'm also sure it isn't 1% either. The reality is so much more interesting than "30%-50% of all crates have `unsafe` in them." And that reality could very well undercut the entire point Sutter is making in this part of the article.