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.)
progbits 4 hours ago [-]
The code is also clearly all vibecoded.
I think this is the usual we get these days: "Show HN: I built..." where in fact author did write neither the code nor the writeup.
rawling 2 hours ago [-]
Is the "chore" commit subject prefix an AI thing? I've started seeing that at work too...
This was a thing before LLMs, but you’d frequently see it in open source repos. So LLMs are just regurgitating what they saw.
2 hours ago [-]
ameliaquining 3 hours ago [-]
Maybe they just didn't want to deal with people arguing about our field's current omnipresent discourse topic in the context of their project?
nxc18 3 hours ago [-]
I find it’s incredibly rude to subject coworkers or members of the public to reading vibe slop.
I don’t mind it under either of two conditions:
1. The slop is used as a starting point only - then thoroughly reviewed and edited to meet a human quality level
2. The article discloses up front that it is AI slop so I can decide if I want to spend my valuable time engaging with it.
nu11ptr 4 hours ago [-]
> It’s the language behind Kubernetes admission policies, Envoy’s RBAC rules, Google Cloud IAM conditions, and gRPC’s protovalidate
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.
akshayshah 4 hours ago [-]
Very fair point that protovalidate comes from Buf, not Google.
But it's worth noting that protovalidate can also work with plain gRPC - it's an independent library, and anyone can write a gRPC interceptor that uses it. Here's a community-supported example in Go: https://pkg.go.dev/github.com/grpc-ecosystem/go-grpc-middlew...
javier2 3 hours ago [-]
I think its more important that protovalidate is not affiliated with grpc in any way. One needs a custom middleware to implement the protovalidate rules for your language used.
xeonax 5 hours ago [-]
This seems like it might be good way to guard state transitions in my PLM/PDM project
Rendered at 20:17:35 GMT+0000 (Coordinated Universal Time) with Vercel.
The omission is especially striking since most of the article sounds AI-authored to me. (Pangram agrees, for what that's worth.)
I think this is the usual we get these days: "Show HN: I built..." where in fact author did write neither the code nor the writeup.
I've always liked them and tried to convince others to use them
AI models seem to like them as well
[1] https://www.conventionalcommits.org/en/v1.0.0/#summary
I don’t mind it under either of two conditions:
1. The slop is used as a starting point only - then thoroughly reviewed and edited to meet a human quality level
2. The article discloses up front that it is AI slop so I can decide if I want to spend my valuable time engaging with it.
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.
But it's worth noting that protovalidate can also work with plain gRPC - it's an independent library, and anyone can write a gRPC interceptor that uses it. Here's a community-supported example in Go: https://pkg.go.dev/github.com/grpc-ecosystem/go-grpc-middlew...