{"slug": "protocol-buffers", "name": "Protocol Buffers", "category": "dev-libs", "category_name": "Libraries and frameworks", "description": "Google's language-neutral binary serialization format and schema language for structured data.", "recommenders": 5, "commenters": 14, "warners": 1, "score": 5.231, "rising": -0.31, "first": "2025-12-01", "latest": "2026-10-14", "why": "Liked for typed schemas shared across languages and compact, efficient data exchange.", "why_is_quote": false, "has_verdict": true, "sentiment": {"recommend": 5, "neutral": 5, "compare": 3, "warn": 1}, "spark": [0, 1, 2, 0, 0, 0, 0, 0, 1, 1, 0, 0], "listed": true, "loved": ["Cross-language schemas", "Efficient exchange"], "caveat": "Design flaws", "short_quote": "The protobuf language is not great, but it's about the right balance between too expressive and too restricting.", "icon": true, "domain": "protobuf.dev", "github_repo": null, "official_url": "https://protobuf.dev", "pricing": "open source", "aliases": ["Protocol Buffers", "Protobuf"], "verdict": [{"text": "Liked for typed schemas shared across languages", "cites": [{"id": 747793585, "item_id": 46737099, "url": "https://news.ycombinator.com/item?id=46737099", "by": "lfittl", "date": "2026-01-23", "stance": "recommend", "quote": "Protobuf makes it easy to have typed bindings in the different languages we support", "excerpt": "Since there seems to be some confusion in the comments about why pg_query chose Protobufs in the first place, let me add some context as the original author of pg_query (but not involved with PgDog, though Lev has shared this work by email beforehand). The initial motivation for developing pg_query was for pganalyze, where we use it to parse queries extracted from Postgres, to find the referenced tables, and these da", "context": "original author of pg_query", "use_case": "AST serialization across bindings", "switched_from": "JSON", "story": "Replacing Protobuf with Rust to go 5 times faster"}, {"id": 789175312, "item_id": 49323457, "url": "https://news.ycombinator.com/item?id=49323457", "by": "tomtom1337", "date": "2026-08-16", "stance": "neutral", "quote": "We use protobuf between c# and Python.", "excerpt": "What are good alternatives when you need a common \"single source of truth\" schema shared between multiple languages? We use protobuf between c# and Python.", "context": "", "use_case": "shared schema between C# and Python", "switched_from": "", "story": "Protobuf has LSP support. You're welcome"}, {"id": 789173248, "item_id": 49323328, "url": "https://news.ycombinator.com/item?id=49323328", "by": "cyberax", "date": "2026-08-16", "stance": "recommend", "quote": "The protobuf language is not great, but it's about the right balance between too expressive and too restricting.", "excerpt": "Anybody who thinks that you can just chuck unstructured data into LLM and YOLO the app is an idiot. This works up to a point, and then it doesn't. And you're left with tons of inconsistently formatted data. My company is built on protobufs from ground up :) We use it in the database, for remote calls, on the frontend, etc. The protobuf language is not great, but it's about the right balance between too expressive and", "context": "company built on protobufs", "use_case": "database, RPC and frontend schemas", "switched_from": "", "story": "Protobuf has LSP support. You're welcome"}]}, {"text": " and compact, efficient data exchange.", "cites": [{"id": 789173248, "item_id": 49323328, "url": "https://news.ycombinator.com/item?id=49323328", "by": "cyberax", "date": "2026-08-16", "stance": "recommend", "quote": "The protobuf language is not great, but it's about the right balance between too expressive and too restricting.", "excerpt": "Anybody who thinks that you can just chuck unstructured data into LLM and YOLO the app is an idiot. This works up to a point, and then it doesn't. And you're left with tons of inconsistently formatted data. My company is built on protobufs from ground up :) We use it in the database, for remote calls, on the frontend, etc. The protobuf language is not great, but it's about the right balance between too expressive and", "context": "company built on protobufs", "use_case": "database, RPC and frontend schemas", "switched_from": "", "story": "Protobuf has LSP support. You're welcome"}, {"id": 780810288, "item_id": 48800643, "url": "https://news.ycombinator.com/item?id=48800643", "by": "frollogaston", "date": "2026-07-05", "stance": "recommend", "quote": "Protobuf does it very well.", "excerpt": "JSON does data exchange ok. Protobuf does it very well. Google fumbled its ecosystem, should've focused on establishing it as an easy alternative to HTTP+JSON, instead focused on gRPC which is its own thing. Textproto is quite readable and supports comments, great for config files. XML is so much fuss for nothing. All that xmlns uri whatever stuff and it still doesn't tell the other side how to parse it.", "context": "", "use_case": "data exchange", "switched_from": "", "story": "Do you hate XML? (2010)"}, {"id": 747705824, "item_id": 46731614, "url": "https://news.ycombinator.com/item?id=46731614", "by": "sylware", "date": "2026-01-23", "stance": "recommend", "quote": "I used protobuf for map data, but it is a hardcore simple format", "excerpt": "I don't understand, I used protobuf for map data, but it is a hardcore simple format, this is the whole purpose of it. I wrote assembly, memory mapping oriented protobuf software... in assembly, then what? I am allowed to say I am going 1000 times faster than rust now???", "context": "", "use_case": "map data serialization", "switched_from": "", "story": "Replacing Protobuf with Rust to go 5 times faster"}]}, {"text": " The most common complaints are design flaws and serializer complexity", "cites": [{"id": 757156353, "item_id": 47322272, "url": "https://news.ycombinator.com/item?id=47322272", "by": "gepheum", "date": "2026-03-10", "stance": "compare", "quote": "although I think it's great, it carries a few design flaws which are hard to fix at this point", "excerpt": "Hey, thanks a lot for the comment! I share your frustration with protobuf: although I think it's great, it carries a few design flaws which are hard to fix at this point and they create pain points which are not going away. I completely agree with you about timing, wish I had done this 10 years ago :) \"Here is an idea to contemplate as a side gig with your favorite Ai assistant: A tool to convert proto to Skir. Or at", "context": "", "use_case": "serialization schemas", "switched_from": "", "story": "Show HN: Skir \u2013 A schema language I built after 15 years of Protobuf friction"}, {"id": 737793808, "item_id": 46112113, "url": "https://news.ycombinator.com/item?id=46112113", "by": "brabel", "date": "2025-12-01", "stance": "compare", "quote": "Protobuf is ok but if you actually look at how the serializers work, it's just too complex for what it achieves.", "excerpt": "Mandatory comment about ASN.1, a protocol from 1984, already did what Protobuf does, with more flexibility. Yes, it's a bit ugly but if you stick to the DER encoding it's really not worse than Protbuf at all. Check out the Wikipedia example: https://en.wikipedia.org/wiki/ASN.1#Example_encoded_in_DER Protobuf is ok but if you actually look at how the serializers work, it's just too complex for what it achieves.", "context": "", "use_case": "serialization", "switched_from": "", "story": "Why I stopped using JSON for my APIs"}, {"id": 789173248, "item_id": 49323328, "url": "https://news.ycombinator.com/item?id=49323328", "by": "cyberax", "date": "2026-08-16", "stance": "recommend", "quote": "The protobuf language is not great, but it's about the right balance between too expressive and too restricting.", "excerpt": "Anybody who thinks that you can just chuck unstructured data into LLM and YOLO the app is an idiot. This works up to a point, and then it doesn't. And you're left with tons of inconsistently formatted data. My company is built on protobufs from ground up :) We use it in the database, for remote calls, on the frontend, etc. The protobuf language is not great, but it's about the right balance between too expressive and", "context": "company built on protobufs", "use_case": "database, RPC and frontend schemas", "switched_from": "", "story": "Protobuf has LSP support. You're welcome"}]}, {"text": ", plus painful gRPC integration in modern stacks.", "cites": [{"id": 789268240, "item_id": 49329265, "url": "https://news.ycombinator.com/item?id=49329265", "by": "PufPufPuf", "date": "2026-08-17", "stance": "warn", "quote": "The promise of Protobuf/gRPC for seamless communication across tech stacks just wasn't delivered.", "excerpt": "The promise of Protobuf/gRPC for seamless communication across tech stacks just wasn't delivered. Third party projects like Buf or BetterProto for Python try their best but it's still a nightmare trying to integrate with gRPC from something remotely modern, like Python with uv and async/await. Plus there's a lot of little pains like not being human-readable, always requiring HTTP/2 and thus HTTPS, and so on. JSON isn", "context": "", "use_case": "cross-language communication", "switched_from": "", "story": "Protobuf has LSP support. You're welcome"}, {"id": 780810288, "item_id": 48800643, "url": "https://news.ycombinator.com/item?id=48800643", "by": "frollogaston", "date": "2026-07-05", "stance": "recommend", "quote": "Protobuf does it very well.", "excerpt": "JSON does data exchange ok. Protobuf does it very well. Google fumbled its ecosystem, should've focused on establishing it as an easy alternative to HTTP+JSON, instead focused on gRPC which is its own thing. Textproto is quite readable and supports comments, great for config files. XML is so much fuss for nothing. All that xmlns uri whatever stuff and it still doesn't tell the other side how to parse it.", "context": "", "use_case": "data exchange", "switched_from": "", "story": "Do you hate XML? (2010)"}]}], "praise": [{"label": "Cross-language schemas", "summary": "A single .proto schema gives typed bindings shared between languages like C# and Python.", "quotes": [{"id": 747793585, "item_id": 46737099, "url": "https://news.ycombinator.com/item?id=46737099", "by": "lfittl", "date": "2026-01-23", "stance": "recommend", "quote": "Protobuf makes it easy to have typed bindings in the different languages we support", "excerpt": "Since there seems to be some confusion in the comments about why pg_query chose Protobufs in the first place, let me add some context as the original author of pg_query (but not involved with PgDog, though Lev has shared this work by email beforehand). The initial motivation for developing pg_query was for pganalyze, where we use it to parse queries extracted from Postgres, to find the referenced tables, and these da", "context": "original author of pg_query", "use_case": "AST serialization across bindings", "switched_from": "JSON", "story": "Replacing Protobuf with Rust to go 5 times faster"}, {"id": 789175312, "item_id": 49323457, "url": "https://news.ycombinator.com/item?id=49323457", "by": "tomtom1337", "date": "2026-08-16", "stance": "neutral", "quote": "We use protobuf between c# and Python.", "excerpt": "What are good alternatives when you need a common \"single source of truth\" schema shared between multiple languages? We use protobuf between c# and Python.", "context": "", "use_case": "shared schema between C# and Python", "switched_from": "", "story": "Protobuf has LSP support. You're welcome"}, {"id": 789173248, "item_id": 49323328, "url": "https://news.ycombinator.com/item?id=49323328", "by": "cyberax", "date": "2026-08-16", "stance": "recommend", "quote": "The protobuf language is not great, but it's about the right balance between too expressive and too restricting.", "excerpt": "Anybody who thinks that you can just chuck unstructured data into LLM and YOLO the app is an idiot. This works up to a point, and then it doesn't. And you're left with tons of inconsistently formatted data. My company is built on protobufs from ground up :) We use it in the database, for remote calls, on the frontend, etc. The protobuf language is not great, but it's about the right balance between too expressive and", "context": "company built on protobufs", "use_case": "database, RPC and frontend schemas", "switched_from": "", "story": "Protobuf has LSP support. You're welcome"}]}, {"label": "Efficient exchange", "summary": "Commenters call it compact and well suited to data exchange.", "quotes": [{"id": 789173248, "item_id": 49323328, "url": "https://news.ycombinator.com/item?id=49323328", "by": "cyberax", "date": "2026-08-16", "stance": "recommend", "quote": "The protobuf language is not great, but it's about the right balance between too expressive and too restricting.", "excerpt": "Anybody who thinks that you can just chuck unstructured data into LLM and YOLO the app is an idiot. This works up to a point, and then it doesn't. And you're left with tons of inconsistently formatted data. My company is built on protobufs from ground up :) We use it in the database, for remote calls, on the frontend, etc. The protobuf language is not great, but it's about the right balance between too expressive and", "context": "company built on protobufs", "use_case": "database, RPC and frontend schemas", "switched_from": "", "story": "Protobuf has LSP support. You're welcome"}, {"id": 780810288, "item_id": 48800643, "url": "https://news.ycombinator.com/item?id=48800643", "by": "frollogaston", "date": "2026-07-05", "stance": "recommend", "quote": "Protobuf does it very well.", "excerpt": "JSON does data exchange ok. Protobuf does it very well. Google fumbled its ecosystem, should've focused on establishing it as an easy alternative to HTTP+JSON, instead focused on gRPC which is its own thing. Textproto is quite readable and supports comments, great for config files. XML is so much fuss for nothing. All that xmlns uri whatever stuff and it still doesn't tell the other side how to parse it.", "context": "", "use_case": "data exchange", "switched_from": "", "story": "Do you hate XML? (2010)"}, {"id": 747705824, "item_id": 46731614, "url": "https://news.ycombinator.com/item?id=46731614", "by": "sylware", "date": "2026-01-23", "stance": "recommend", "quote": "I used protobuf for map data, but it is a hardcore simple format", "excerpt": "I don't understand, I used protobuf for map data, but it is a hardcore simple format, this is the whole purpose of it. I wrote assembly, memory mapping oriented protobuf software... in assembly, then what? I am allowed to say I am going 1000 times faster than rust now???", "context": "", "use_case": "map data serialization", "switched_from": "", "story": "Replacing Protobuf with Rust to go 5 times faster"}]}, {"label": "Readable text format", "summary": "Textproto is readable, supports comments, and works well for config files.", "quotes": [{"id": 737922608, "item_id": 46120163, "url": "https://news.ycombinator.com/item?id=46120163", "by": "pjacotg", "date": "2025-12-02", "stance": "recommend", "quote": "we use protobuf converted to text format. It looks JSON like so very readable and comes with all the other benefits of protobuf.", "excerpt": "On the human readability concern, we use protobuf converted to text format. It looks JSON like so very readable and comes with all the other benefits of protobuf.", "context": "", "use_case": "API serialization", "switched_from": "", "story": "Why I stopped using JSON for my APIs"}, {"id": 780810288, "item_id": 48800643, "url": "https://news.ycombinator.com/item?id=48800643", "by": "frollogaston", "date": "2026-07-05", "stance": "recommend", "quote": "Protobuf does it very well.", "excerpt": "JSON does data exchange ok. Protobuf does it very well. Google fumbled its ecosystem, should've focused on establishing it as an easy alternative to HTTP+JSON, instead focused on gRPC which is its own thing. Textproto is quite readable and supports comments, great for config files. XML is so much fuss for nothing. All that xmlns uri whatever stuff and it still doesn't tell the other side how to parse it.", "context": "", "use_case": "data exchange", "switched_from": "", "story": "Do you hate XML? (2010)"}]}, {"label": "Balanced language", "summary": "The schema language is seen as about the right balance between too expressive and too restrictive.", "quotes": [{"id": 789173248, "item_id": 49323328, "url": "https://news.ycombinator.com/item?id=49323328", "by": "cyberax", "date": "2026-08-16", "stance": "recommend", "quote": "The protobuf language is not great, but it's about the right balance between too expressive and too restricting.", "excerpt": "Anybody who thinks that you can just chuck unstructured data into LLM and YOLO the app is an idiot. This works up to a point, and then it doesn't. And you're left with tons of inconsistently formatted data. My company is built on protobufs from ground up :) We use it in the database, for remote calls, on the frontend, etc. The protobuf language is not great, but it's about the right balance between too expressive and", "context": "company built on protobufs", "use_case": "database, RPC and frontend schemas", "switched_from": "", "story": "Protobuf has LSP support. You're welcome"}]}], "caveats": [{"label": "Design flaws", "summary": "Commenters cite hard-to-fix design flaws, an imperfect language, and overly complex serializers.", "quotes": [{"id": 757156353, "item_id": 47322272, "url": "https://news.ycombinator.com/item?id=47322272", "by": "gepheum", "date": "2026-03-10", "stance": "compare", "quote": "although I think it's great, it carries a few design flaws which are hard to fix at this point", "excerpt": "Hey, thanks a lot for the comment! I share your frustration with protobuf: although I think it's great, it carries a few design flaws which are hard to fix at this point and they create pain points which are not going away. I completely agree with you about timing, wish I had done this 10 years ago :) \"Here is an idea to contemplate as a side gig with your favorite Ai assistant: A tool to convert proto to Skir. Or at", "context": "", "use_case": "serialization schemas", "switched_from": "", "story": "Show HN: Skir \u2013 A schema language I built after 15 years of Protobuf friction"}, {"id": 737793808, "item_id": 46112113, "url": "https://news.ycombinator.com/item?id=46112113", "by": "brabel", "date": "2025-12-01", "stance": "compare", "quote": "Protobuf is ok but if you actually look at how the serializers work, it's just too complex for what it achieves.", "excerpt": "Mandatory comment about ASN.1, a protocol from 1984, already did what Protobuf does, with more flexibility. Yes, it's a bit ugly but if you stick to the DER encoding it's really not worse than Protbuf at all. Check out the Wikipedia example: https://en.wikipedia.org/wiki/ASN.1#Example_encoded_in_DER Protobuf is ok but if you actually look at how the serializers work, it's just too complex for what it achieves.", "context": "", "use_case": "serialization", "switched_from": "", "story": "Why I stopped using JSON for my APIs"}, {"id": 789173248, "item_id": 49323328, "url": "https://news.ycombinator.com/item?id=49323328", "by": "cyberax", "date": "2026-08-16", "stance": "recommend", "quote": "The protobuf language is not great, but it's about the right balance between too expressive and too restricting.", "excerpt": "Anybody who thinks that you can just chuck unstructured data into LLM and YOLO the app is an idiot. This works up to a point, and then it doesn't. And you're left with tons of inconsistently formatted data. My company is built on protobufs from ground up :) We use it in the database, for remote calls, on the frontend, etc. The protobuf language is not great, but it's about the right balance between too expressive and", "context": "company built on protobufs", "use_case": "database, RPC and frontend schemas", "switched_from": "", "story": "Protobuf has LSP support. You're welcome"}]}, {"label": "gRPC ecosystem", "summary": "Integrating gRPC from modern stacks like async Python is described as a nightmare, and the ecosystem as fumbled.", "quotes": [{"id": 789268240, "item_id": 49329265, "url": "https://news.ycombinator.com/item?id=49329265", "by": "PufPufPuf", "date": "2026-08-17", "stance": "warn", "quote": "The promise of Protobuf/gRPC for seamless communication across tech stacks just wasn't delivered.", "excerpt": "The promise of Protobuf/gRPC for seamless communication across tech stacks just wasn't delivered. Third party projects like Buf or BetterProto for Python try their best but it's still a nightmare trying to integrate with gRPC from something remotely modern, like Python with uv and async/await. Plus there's a lot of little pains like not being human-readable, always requiring HTTP/2 and thus HTTPS, and so on. JSON isn", "context": "", "use_case": "cross-language communication", "switched_from": "", "story": "Protobuf has LSP support. You're welcome"}, {"id": 780810288, "item_id": 48800643, "url": "https://news.ycombinator.com/item?id=48800643", "by": "frollogaston", "date": "2026-07-05", "stance": "recommend", "quote": "Protobuf does it very well.", "excerpt": "JSON does data exchange ok. Protobuf does it very well. Google fumbled its ecosystem, should've focused on establishing it as an easy alternative to HTTP+JSON, instead focused on gRPC which is its own thing. Textproto is quite readable and supports comments, great for config files. XML is so much fuss for nothing. All that xmlns uri whatever stuff and it still doesn't tell the other side how to parse it.", "context": "", "use_case": "data exchange", "switched_from": "", "story": "Do you hate XML? (2010)"}]}, {"label": "No safety guarantees", "summary": "proto3 has no required fields and version skew breaks assumptions, so clients must be written defensively.", "quotes": [{"id": 737847136, "item_id": 46115446, "url": "https://news.ycombinator.com/item?id=46115446", "by": "dfabulich", "date": "2025-12-01", "stance": "neutral", "quote": "Protobuf clients need to be written defensively, just like JSON API clients.", "excerpt": "> With JSON, you often send ambiguous or non-guaranteed data. You may encounter a missing field, an incorrect type, a typo in a key, or simply an undocumented structure. With Protobuf, that\u2019s impossible. Everything starts with a .proto file that defines the structure of messages precisely. This deeply misunderstands the philosophy of Protobuf. proto3 doesn't even support required fields. https://protobuf.dev/best-pra", "context": "", "use_case": "API serialization", "switched_from": "", "story": "Why I stopped using JSON for my APIs"}, {"id": 737790352, "item_id": 46111897, "url": "https://news.ycombinator.com/item?id=46111897", "by": "pzmarzly", "date": "2025-12-01", "stance": "neutral", "quote": "it seems like protobuf3 fixed a lot of stuff I used to hate about protobuf2.", "excerpt": "> With Protobuf, that\u2019s impossible. Unless your servers and clients push at different time, thus are compiled with different versions of your specs, then many safety bets are off. There are ways to be mostly safe (never reuse IDs, use unknown-field-friendly copying methods, etc.), but distributed systems are distributed systems, and protobuf isn't a silver bullet that can solve all problems on author's list. On the u", "context": "", "use_case": "API serialization", "switched_from": "", "story": "Why I stopped using JSON for my APIs"}]}, {"label": "Rigid schema", "summary": "The strict schema requirement misses many use cases where JSON thrives.", "quotes": [{"id": 737789233, "item_id": 46111827, "url": "https://news.ycombinator.com/item?id=46111827", "by": "codewritero", "date": "2025-12-01", "stance": "compare", "quote": "Protobuf has advantages, but is missing support for a tons of use cases where JSON thrives due to the strict schema requirement.", "excerpt": "I love to see people advocating for better protocols and standards but seeing the title I expected the author to present something which would be better in the sense of supporting the same or more use cases with better efficiency and/or ergonomics and I don't think that protobuf does that. Protobuf has advantages, but is missing support for a tons of use cases where JSON thrives due to the strict schema requirement. ", "context": "", "use_case": "", "switched_from": "", "story": "Why I stopped using JSON for my APIs"}]}, {"label": "Not human-readable", "summary": "The binary wire format is not human-readable.", "quotes": [{"id": 789268240, "item_id": 49329265, "url": "https://news.ycombinator.com/item?id=49329265", "by": "PufPufPuf", "date": "2026-08-17", "stance": "warn", "quote": "The promise of Protobuf/gRPC for seamless communication across tech stacks just wasn't delivered.", "excerpt": "The promise of Protobuf/gRPC for seamless communication across tech stacks just wasn't delivered. Third party projects like Buf or BetterProto for Python try their best but it's still a nightmare trying to integrate with gRPC from something remotely modern, like Python with uv and async/await. Plus there's a lot of little pains like not being human-readable, always requiring HTTP/2 and thus HTTPS, and so on. JSON isn", "context": "", "use_case": "cross-language communication", "switched_from": "", "story": "Protobuf has LSP support. You're welcome"}]}], "who": [{"by": "cyberax", "context": "company built on protobufs", "url": "https://news.ycombinator.com/item?id=49323328", "date": "2026-08-16"}, {"by": "lfittl", "context": "original author of pg_query", "url": "https://news.ycombinator.com/item?id=46737099", "date": "2026-01-23"}], "tags": ["for multi-language codebases", "for service APIs", "for config files"], "use_cases": ["api serialization", "enforcing service boundaries in ai-written code", "cross-language communication", "shared schema between c# and python", "database, rpc and frontend schemas", "data exchange"], "compared": [], "makers": [], "threads": [{"url": "https://news.ycombinator.com/item?id=46111469", "title": "Why I stopped using JSON for my APIs", "mentions": 5}, {"url": "https://news.ycombinator.com/item?id=49322573", "title": "Protobuf has LSP support. You're welcome", "mentions": 3}, {"url": "https://news.ycombinator.com/item?id=46730214", "title": "Replacing Protobuf with Rust to go 5 times faster", "mentions": 2}, {"url": "https://news.ycombinator.com/item?id=50073633", "title": "Redesigning source control at Anthropic", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=48796438", "title": "Do you hate XML? (2010)", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=47299022", "title": "Show HN: Skir \u2013 A schema language I built after 15 years of Protobuf friction", "mentions": 1}], "sentiment_by_month": {"2025-11": {}, "2025-12": {"compare": 2, "neutral": 2, "recommend": 1}, "2026-01": {"recommend": 2}, "2026-02": {"neutral": 1}, "2026-03": {"compare": 1}, "2026-04": {}, "2026-05": {}, "2026-06": {}, "2026-07": {"recommend": 1}, "2026-08": {"recommend": 1, "neutral": 1, "warn": 1}, "2026-09": {}, "2026-10": {"neutral": 1}}, "quotes": [{"id": 801373488, "item_id": 50085843, "url": "https://news.ycombinator.com/item?id=50085843", "by": "iforgotmypasswo", "date": "2026-10-14", "stance": "neutral", "quote": "I\u2019ve been getting overzealous with protobuffers and service discovery as well.", "excerpt": "tl;dr - With AI code is cheap, but poor architecture and skipping best practices is very very expensive. Markdown files will not solve this problem, but it can be solved. In my case, \u201cFactory\u201d is hundreds of architectural tests built over thousands of application specific tests, and a couple MD files here or there. The MDs are mostly reference material and common patterns. The tests are what actually enforce feature/", "context": "", "use_case": "enforcing service boundaries in AI-written code", "switched_from": "", "story": "Redesigning source control at Anthropic"}, {"id": 789268240, "item_id": 49329265, "url": "https://news.ycombinator.com/item?id=49329265", "by": "PufPufPuf", "date": "2026-08-17", "stance": "warn", "quote": "The promise of Protobuf/gRPC for seamless communication across tech stacks just wasn't delivered.", "excerpt": "The promise of Protobuf/gRPC for seamless communication across tech stacks just wasn't delivered. Third party projects like Buf or BetterProto for Python try their best but it's still a nightmare trying to integrate with gRPC from something remotely modern, like Python with uv and async/await. Plus there's a lot of little pains like not being human-readable, always requiring HTTP/2 and thus HTTPS, and so on. JSON isn", "context": "", "use_case": "cross-language communication", "switched_from": "", "story": "Protobuf has LSP support. You're welcome"}, {"id": 789175312, "item_id": 49323457, "url": "https://news.ycombinator.com/item?id=49323457", "by": "tomtom1337", "date": "2026-08-16", "stance": "neutral", "quote": "We use protobuf between c# and Python.", "excerpt": "What are good alternatives when you need a common \"single source of truth\" schema shared between multiple languages? We use protobuf between c# and Python.", "context": "", "use_case": "shared schema between C# and Python", "switched_from": "", "story": "Protobuf has LSP support. You're welcome"}, {"id": 789173248, "item_id": 49323328, "url": "https://news.ycombinator.com/item?id=49323328", "by": "cyberax", "date": "2026-08-16", "stance": "recommend", "quote": "The protobuf language is not great, but it's about the right balance between too expressive and too restricting.", "excerpt": "Anybody who thinks that you can just chuck unstructured data into LLM and YOLO the app is an idiot. This works up to a point, and then it doesn't. And you're left with tons of inconsistently formatted data. My company is built on protobufs from ground up :) We use it in the database, for remote calls, on the frontend, etc. The protobuf language is not great, but it's about the right balance between too expressive and", "context": "company built on protobufs", "use_case": "database, RPC and frontend schemas", "switched_from": "", "story": "Protobuf has LSP support. You're welcome"}, {"id": 780810288, "item_id": 48800643, "url": "https://news.ycombinator.com/item?id=48800643", "by": "frollogaston", "date": "2026-07-05", "stance": "recommend", "quote": "Protobuf does it very well.", "excerpt": "JSON does data exchange ok. Protobuf does it very well. Google fumbled its ecosystem, should've focused on establishing it as an easy alternative to HTTP+JSON, instead focused on gRPC which is its own thing. Textproto is quite readable and supports comments, great for config files. XML is so much fuss for nothing. All that xmlns uri whatever stuff and it still doesn't tell the other side how to parse it.", "context": "", "use_case": "data exchange", "switched_from": "", "story": "Do you hate XML? (2010)"}, {"id": 757156353, "item_id": 47322272, "url": "https://news.ycombinator.com/item?id=47322272", "by": "gepheum", "date": "2026-03-10", "stance": "compare", "quote": "although I think it's great, it carries a few design flaws which are hard to fix at this point", "excerpt": "Hey, thanks a lot for the comment! I share your frustration with protobuf: although I think it's great, it carries a few design flaws which are hard to fix at this point and they create pain points which are not going away. I completely agree with you about timing, wish I had done this 10 years ago :) \"Here is an idea to contemplate as a side gig with your favorite Ai assistant: A tool to convert proto to Skir. Or at", "context": "", "use_case": "serialization schemas", "switched_from": "", "story": "Show HN: Skir \u2013 A schema language I built after 15 years of Protobuf friction"}, {"id": 752286832, "item_id": 47017927, "url": "https://news.ycombinator.com/item?id=47017927", "by": "PessimalDecimal", "date": "2026-02-14", "stance": "neutral", "quote": "My guess is there's more to that story than just \"protobufs don't forward unknown fields\" because that's not how they work be default.", "excerpt": "My guess is there's more to that story than just \"protobufs don't forward unknown fields\" because that's not how they work be default. Take a look at https://protobuf.dev/programming-guides/proto3/#unknowns. https://kmcd.dev/posts/protobuf-unknown-fields/ discusses the scenario you're hinting at. It's possible in the story you mention that each of those ~20 internal protos were different messages, and each hop betwee", "context": "", "use_case": "service serialization", "switched_from": "", "story": "gRPC: From service definition to wire format"}, {"id": 747793585, "item_id": 46737099, "url": "https://news.ycombinator.com/item?id=46737099", "by": "lfittl", "date": "2026-01-23", "stance": "recommend", "quote": "Protobuf makes it easy to have typed bindings in the different languages we support", "excerpt": "Since there seems to be some confusion in the comments about why pg_query chose Protobufs in the first place, let me add some context as the original author of pg_query (but not involved with PgDog, though Lev has shared this work by email beforehand). The initial motivation for developing pg_query was for pganalyze, where we use it to parse queries extracted from Postgres, to find the referenced tables, and these da", "context": "original author of pg_query", "use_case": "AST serialization across bindings", "switched_from": "JSON", "story": "Replacing Protobuf with Rust to go 5 times faster"}, {"id": 747705824, "item_id": 46731614, "url": "https://news.ycombinator.com/item?id=46731614", "by": "sylware", "date": "2026-01-23", "stance": "recommend", "quote": "I used protobuf for map data, but it is a hardcore simple format", "excerpt": "I don't understand, I used protobuf for map data, but it is a hardcore simple format, this is the whole purpose of it. I wrote assembly, memory mapping oriented protobuf software... in assembly, then what? I am allowed to say I am going 1000 times faster than rust now???", "context": "", "use_case": "map data serialization", "switched_from": "", "story": "Replacing Protobuf with Rust to go 5 times faster"}, {"id": 737922608, "item_id": 46120163, "url": "https://news.ycombinator.com/item?id=46120163", "by": "pjacotg", "date": "2025-12-02", "stance": "recommend", "quote": "we use protobuf converted to text format. It looks JSON like so very readable and comes with all the other benefits of protobuf.", "excerpt": "On the human readability concern, we use protobuf converted to text format. It looks JSON like so very readable and comes with all the other benefits of protobuf.", "context": "", "use_case": "API serialization", "switched_from": "", "story": "Why I stopped using JSON for my APIs"}, {"id": 737847136, "item_id": 46115446, "url": "https://news.ycombinator.com/item?id=46115446", "by": "dfabulich", "date": "2025-12-01", "stance": "neutral", "quote": "Protobuf clients need to be written defensively, just like JSON API clients.", "excerpt": "> With JSON, you often send ambiguous or non-guaranteed data. You may encounter a missing field, an incorrect type, a typo in a key, or simply an undocumented structure. With Protobuf, that\u2019s impossible. Everything starts with a .proto file that defines the structure of messages precisely. This deeply misunderstands the philosophy of Protobuf. proto3 doesn't even support required fields. https://protobuf.dev/best-pra", "context": "", "use_case": "API serialization", "switched_from": "", "story": "Why I stopped using JSON for my APIs"}, {"id": 737793808, "item_id": 46112113, "url": "https://news.ycombinator.com/item?id=46112113", "by": "brabel", "date": "2025-12-01", "stance": "compare", "quote": "Protobuf is ok but if you actually look at how the serializers work, it's just too complex for what it achieves.", "excerpt": "Mandatory comment about ASN.1, a protocol from 1984, already did what Protobuf does, with more flexibility. Yes, it's a bit ugly but if you stick to the DER encoding it's really not worse than Protbuf at all. Check out the Wikipedia example: https://en.wikipedia.org/wiki/ASN.1#Example_encoded_in_DER Protobuf is ok but if you actually look at how the serializers work, it's just too complex for what it achieves.", "context": "", "use_case": "serialization", "switched_from": "", "story": "Why I stopped using JSON for my APIs"}, {"id": 737790352, "item_id": 46111897, "url": "https://news.ycombinator.com/item?id=46111897", "by": "pzmarzly", "date": "2025-12-01", "stance": "neutral", "quote": "it seems like protobuf3 fixed a lot of stuff I used to hate about protobuf2.", "excerpt": "> With Protobuf, that\u2019s impossible. Unless your servers and clients push at different time, thus are compiled with different versions of your specs, then many safety bets are off. There are ways to be mostly safe (never reuse IDs, use unknown-field-friendly copying methods, etc.), but distributed systems are distributed systems, and protobuf isn't a silver bullet that can solve all problems on author's list. On the u", "context": "", "use_case": "API serialization", "switched_from": "", "story": "Why I stopped using JSON for my APIs"}, {"id": 737789233, "item_id": 46111827, "url": "https://news.ycombinator.com/item?id=46111827", "by": "codewritero", "date": "2025-12-01", "stance": "compare", "quote": "Protobuf has advantages, but is missing support for a tons of use cases where JSON thrives due to the strict schema requirement.", "excerpt": "I love to see people advocating for better protocols and standards but seeing the title I expected the author to present something which would be better in the sense of supporting the same or more use cases with better efficiency and/or ergonomics and I don't think that protobuf does that. Protobuf has advantages, but is missing support for a tons of use cases where JSON thrives due to the strict schema requirement. ", "context": "", "use_case": "", "switched_from": "", "story": "Why I stopped using JSON for my APIs"}]}