1) Induces a large performance penalty

2) Introduces a GC into C code bases (higher memory requirements, performance profile changes)

3) Is x86-64 only atm I believe

An idiomatic Rust port would have none of these issues, so it would be more a stop gap measure than a long term strategy.

Very small nitpick, but AFAIK protovalidate comes from Buf, not Google. While protovalidate DOES work with gRPC via backward compatibility (but also Buf's ConnectRPC), saying "gRPC's protovalidate" probably makes people think it came from Google.

Disclaimer: I have no affiliation with either Buf or Google.

Unchecked exceptions lead to unhandled exceptions at runtime. We've all seen screens with Java programs running with tons of exceptions in the log, or worse, that crash with unhandled exceptions. This is the result of the unchecked exceptions mess, which is why I won't use languages that use them for routine error handling for anything more than trivial programs.

Sure, GC's are nice which is why so many langs have them, but that removes the deterministic allocation performance which most C/C++ programmers want (and many times need). Why not just use something like Go then? You have a much richer stdlib available out of the box.

FYI - this article is written by the author of Vale

Languages use Boehm for exactly one reason: it is easy to shim into an otherwise manual memory system (it was designed for use in C/C++). I mean no respect to its authors, but using Boehm in production is the worst of all worlds: slow allocations (free list allocator), poor cache locality, and not precise (so you can expect memory leaks). If you are going to do a GC language you want: 1) precise 2) bump allocator 3) compacting collector 4) generations. Essentially you want to allocate fast, only touch live objects (most objects die young), compact them for locality, and only process objects each cycle of similar age. There is a huge amount of engineering that goes into a state of the art collector, but those are the basics.

If only that could be expressed in the type system. Instead, the programmer is now forced to think about these things everywhere over their entire codebase.

That said, there is value in limiting your own unsafe use, and there might be value in limiting unsafe in the crates you use. However, this is really a question of "who do I trust to use unsafe? How much? Under what circumstances?" and NOT "is okay to have any unsafe?" because any useful program will contain a lot of unsafe if traced far enough in its call paths.

Shortening the lifespan?