maybebug

I fully agree!

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.

Interesting perspective that you have.

Nitpicking ahead:

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.