But why then did you conflate safety and memory safety?
> Rust's standard library is filled with 'unsafe' because one of the design goals of the standard library was "put stuff that needs a lot of unsafe in it, because the Rust team is more likely to write it correctly than other people." That is of course different in 2026.
No, there is a lot of unsafe in both Rust's standard library and in non-standard Rust libraries for multiple reasons, in particular performance for both kinds (std and user/non-std) of libraries. Thus, as I pointed out, for Rust, "unsafe" is in practice often needed for performance in Rust.
Memory safe languages, where usage of Miri and Valgrind (tools to for instance debug memory unsafety) are common and integrated into CI for some of the projects in the language. Even some Rust guides encourages running Miri in CI https://microsoft.github.io/RustTraining/engineering-book/ch... . Searching on GitHub yields a lot of projects that run Miri in CI. And there have been a lot of CVEs for Rust projects caused by memory unsafety.
> 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.
But why then did you conflate safety and memory safety?
> Rust's standard library is filled with 'unsafe' because one of the design goals of the standard library was "put stuff that needs a lot of unsafe in it, because the Rust team is more likely to write it correctly than other people." That is of course different in 2026.
No, there is a lot of unsafe in both Rust's standard library and in non-standard Rust libraries for multiple reasons, in particular performance for both kinds (std and user/non-std) of libraries. Thus, as I pointed out, for Rust, "unsafe" is in practice often needed for performance in Rust.