> I do think it reflects different priorities, but one of those differences is that from my perspective, safety and performance are not inherently at odds. Yes, sometimes it is needed, but not as much as some people seem to think. Sometimes, it also means writing code in ways that communicate things to the compiler that you may not think of if you're not used to thinking in this manner.
But a lot of Rust projects use "unsafe" for the sake of increased performance. Directly citing performance in comments in the code as justification for "unsafe". And the Rust stdlib is filled with "unsafe", like files where more than 50% of the code is inside "unsafe" blocks, for the sake of performance. And then memory safety bugs and CVEs are encountered in such Rust libraries and applications or libraries and applications that have those libraries as dependencies.
And then there is the general mistake regarding wrongful conflation between safety and memory safety that you and many others make. Memory safety is necessary, but not sufficient, for several important types of applications regarding safety and security.
Edit:
> Cool, I'm not sure that people know that we know each other and have some deeper mutual understanding. :)
Jeffrey Epstein knew a lot of people, being well connected, like you, is not necessarily a good and benign thing in itself.
I am not sure, but there might be a bug in their pattern matching example.
What happens if 'verb' is "GET" and 'path' is "/users/1234/posts/1234/extra_path/and/more/"? Will 'post_id' become "extra_path/and/more/"?
I tried running it in the sandbox, and it does indeed seem to buggily result in:
"Post ID: 1234/extra_path/and/more"
I suspect that the reason it is behaving like it is, is due to how it handles characters in the string literal. The example program exploits that only the slashes present in the string literal pattern are matched, to enable matching on 'page' having slashes. But then in the nested 'match', it forgot to account for any possible extra slashes.
Nitpicking end.
I have not read the whole post yet, but the pattern matching not requiring any allocations, seems very nice. The string literal patterns also seem interesting, though I am not completely sold on them, also as per the above possible bug. It seems really clean in some ways, but the specific semantics, I am not fully sure about. Maybe it is excellent, and is so clean and concise that it is overall less bug-prone than alternatives in other programming languages. I do not know.
但为什么要将安全性和内存安全性混为一谈呢？
> Rust 的标准库充满了‘不安全’，因为标准库的设计目标之一是“把需要大量不安全的东西放进去，因为 Rust 团队比其他人更有可能正确地编写它。”到了 2026 年，情况当然有所不同。
不，由于多种原因，Rust 的标准库和非标准 Rust 库都存在很多不安全的地方，特别是两种库（标准库和用户/非标准库）的性能。因此，正如我所指出的，对于 Rust，“不安全”实际上是 Rust 性能所必需的。