akshayshah

Sensible attitude for a one-team codebase, but much harder in a google3-sized megarepo…plus the policy matches protobuf enum semantics.

Huh - are you sure? I was pretty sure that the original implementation came from the Android & iOS repos.

I'm surprised (without any particular positive/negative valence) that the article doesn't mention using AI to write the port - especially since both CEL and protovalidate have fairly extensive conformance testing harnesses. The project should be right in the sweet spot for today's tools.

The omission is especially striking since most of the article sounds AI-authored to me. (Pangram agrees, for what that's worth.)

I'm not sure how to think about what you mean by "almost never." If most commercial software is web frontend + monolithic app code + relational DB, then you may very well be right.

That doesn't quite match my professional experience, though - there are so many companies building databases, message queues, filesystems, and similar infrastructure. Sometimes they're internal projects, and sometimes they're commercial products. I've always felt that those systems would benefit from formal methods, since they're usually trying to provide strong guarantees to the application code on top.

It's strange to see this project on Github: the repository is basically just a README and Github sponsors config, without any source code I can see. Does the Polyform Shield license checked into the repository apply to the released artifacts? Are the the released artifacts trustworthy enough to have access to my microphone?

This is very cool! I’m most interested in the protobuf runtime - Rust has historically used Prost, which doesn’t pass the protobuf compliance test suite and isn’t Google-maintained. Google’s priority internally is cpp interop, so they use unsafe for protobuf - which the community is understandably not excited about.

(For full disclosure, I started the ConnectRPC project - so of course I’m excited about that part of the announcement too.)