Rendered at 11:54:30 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
jvolkman 11 hours ago [-]
> Protobuf now has modern IDE support for the first time
Weird post. I built IntelliJ protobuf support [1] while at Google like 10 years ago, and it started shipping by default with IntelliJ in ~2021. Maybe that's not considered "modern".
Sure, but having a generic LSP that works with all editors vs. an editor specific integration is still a very different thing.
It's a bit odd for the parent commenter to say "Weird post" and implying that having an editor specific feature would somehow make having an LSP that works for everyone be any less interesting.
The bizarre "you're welcome" in the title is so obnoxious that I was sure it would be related to some sort of funny twist in the blog entry. Nope, they really thought that was appropriate.
0xfffafaCrash 5 hours ago [-]
I’ve seen similar wording from colleagues on the ASD (with Asperger’s).
It can be hard for some people to navigate the nuances between usage of a tongue-in-cheek usage of the phrase which is more socially acceptable or humorous from the version that reads as arrogant
3 hours ago [-]
colechristensen 10 hours ago [-]
surely we're not a community so unfamiliar with lacking social skills and this aberration isn't at all important to the topic at hand
Dylan16807 7 hours ago [-]
It sounds like you're having a bad day or something. Putting "you're welcome" in the title of your own blog, on a free software release, is fine. It's not pushed into anyone's face. It loses some points for being a corporate ad but that would happen regardless of wording.
otterley 7 hours ago [-]
I think it makes the author sound like a dick.
Test for yourself: next time you take out the garbage, loudly tell your partner or roommate, “I took out the garbage. You’re welcome.”
Dylan16807 5 hours ago [-]
That's a shared chore. Do you not see the obvious differences in the situation? If they said "you're welcome" about an obligation like paying taxes and also made it very personal, then it would be close in feeling to your scenario. But it's not. If you offer a genuine gift, in a situation where there is no expectation of payback or debt, you can say you're welcome.
otterley 4 hours ago [-]
It’s impolite and weird to say “you’re welcome” when offering a gift for which the recipient did not first express gratitude. It follows “thank you;” it does not precede it.
Try this instead: give a stranger a piece of pre-chewed gum and say “you’re welcome!” Hell, even if it’s not pre-chewed, it’s just presumptuous and rude. You have no idea if they value it or not. They might not even like it.
Even if my barista handed me the coffee I ordered and said “you’re welcome” before I thanked them first, I’d think they’re a little off kilter.
hinkley 4 hours ago [-]
You're working mighty hard to manufacture outrage there.
Coming off more as projecting. Maybe you're being an asshole when you say "You're welcome" but it's a bit how the guy who steals is the first one to accuse others of theft.
otterley 4 hours ago [-]
We’re talking about basic etiquette here. I don’t have to manufacture it. If the score on my comment (which I know you can’t see but you’ll have to take my word for it) and other comments in this discussion that express similar sentiment are any indication (among them, “arrogant” and “obnoxious”), I’m by no means the only person who feels this way.
Try my experiments yourself if you disagree, and come back and let us all know how they went for you.
antonvs 2 hours ago [-]
Perhaps you're unfamiliar with the common passive-agressive use of "you're welcome" in exactly the kind of context the OP article uses it. But it's a thing, even if you haven't come across it.
lacoolj 13 hours ago [-]
"You're welcome" is absolutely hilarious to read from a company post.
trial3 13 hours ago [-]
Your HN comment has a reply. You're welcome.
hinkley 4 hours ago [-]
What can I say, except you're welcome.
bmitc 13 hours ago [-]
It's gotten out of hand. Companies making money think they do everyone a favor.
tredre3 13 hours ago [-]
They are doing us a favor, there's no denying that. Just like dozen of other providers did them a favor by providing them with the free software pieces they relied on to build their product.
Of course it's poor taste to add the "You're welcome". But poor taste is par for the course for such startup, unfortunately.
imoverclocked 12 hours ago [-]
Despite interesting legal definitions, companies are just groups of people.
I also read the title as having an air of self-importance or maybe passive-aggression. If you read it a little more dispassionately then it's just an awkward way of stating that this is a gift.
Why is this a gift? The company does not need to give it to you, though it arguably benefits from doing so. It did so with some definition of "free."
williamcotton 14 hours ago [-]
I looked at the dependencies and noticed that it wasn’t using an existing Protobuf parser which means they reimplemented the parser from scratch. Perhaps due to a lack of error recovery in the existing implementations? I don’t have the energy right now for further inspection.
It is definitely best to reuse the parser for the runtime when implementing an LSP but to do so properly means implementing the parser itself as a standalone library. Even better is shipping the semantic analysis as well!
Implementation drift is definitely an issue.
But great project anyways, just wanted to put my thoughts on the matter into the conversation!
vyaa 14 hours ago [-]
I think its worth considering but I don’t agree it’s always best to use the language parser.
A language parser should be correct. A LSP parser should be fault tolerant. My understanding is you cant have both.
lalitmaganti 14 hours ago [-]
It absolutely can be done [1] but it is a lot of effort to do high quality error recovery. It's easier in languages with natural "synchronization points" [2], harder in languages which don't have them.
Having built a lot of protobuf tooling, I'd estimate that protobuf largely falls into the former camp; most of your time working with .proto files is operating on fields which terminate using `;` at the end of the line (though multi-line is also possible).
[2] e.g. SQL naturally has this at statement and expression boundaries which covers almost all of the cases people care about.
afdbcreid 13 hours ago [-]
Adding to this, rustc's parser is both correct and fault-tolerant, yet rust-analyzer ended up building its own for different reasons (needing a CST and not an AST).
williamcotton 12 hours ago [-]
I settled on starting with a CST using rowan, doing semantic analysis, having an agnostic editor services, exposing both an LSP interface with tower, and a WASM interface (for Monaco in the browser [non-LSP!!]) and having the runtime binary doing the interpretation/compilation with the same pathway, with a slight jog, as the editor services. Phew!
adastra22 14 hours ago [-]
It is my understanding that basically all LSP implementations use tree-sitter because of its incremental rebuild capability, and this requires re-implementing the parser.
afdbcreid 13 hours ago [-]
That's just not true. rust-analyzer does not use tree-sitter. Neither does gopls. Nor Pylance. Or tsc. In fact I don't know if there is a single popular LSP that uses it (but there probably is).
Many editors use tree-sitter, but that is separate from the LSP.
Ah, so does the LSP just call out to the Buf binary?
hxtk 13 hours ago [-]
The LSP is one of the subcommands provided by the buf binary. My LSP configuration for protobuf is `buf lsp serve`.
williamcotton 12 hours ago [-]
Makes sense, thanks for the clarification.
arccy 13 hours ago [-]
The lsp is a subcommand of buf, from the page: `buf lsp serve`
eterm 15 hours ago [-]
Lots of naysayers here, but an advantage of protobuf is that proto files are hand-writeable, and therefore having an LSP for that could be useful.
That said, proto itself dissuades or forbids the kind of common things you might do with a LSP, such as renaming.
Renaming fields is a big no-no [edit: this isn't true, see corrections below], as is doing things like re-ordering fields.
A core idea of proto is that versions are strictly compatible with with previous versions. This itself has limitations and challenges for migrations, but encourages good practice about compatibility that usually gets ignored or hand-waved away in most ecosystems.
I accept however that it's often easy to offload both the re-structuring and the checking of version compatibility to an LLM and let them go at it.
wazzaps 14 hours ago [-]
Actually renaming and reordering fields is completely fine, as long as the field ID and type stay the same
ventana 12 hours ago [-]
Considered breaking change because JSON serialization will change, and JSON is used quite often.
Reordering fields without changing their ID is indeed a non-breaking change from what I understand, albeit quite a useless one :)
imoverclocked 12 hours ago [-]
> a useless one
If you have a (long) list of fields and you want to keep them lexicographically sorted, being able to reorder is quite useful if you rename a field.
ventana 12 hours ago [-]
Renaming is forbidden though (because JSON and textproto). In Google, it's a documented antipattern to try to make protobuf look "nice" by changing field indices, rearranging fields, etc. — the common ground is that it's better to not do it.
dieortin 14 hours ago [-]
Depends, if you use textproto then renaming is problematic too
eterm 14 hours ago [-]
Shit, you're right, I'm trying to remember the one that used to trip us up all the time, maybe it was removing fields?
There was definitely one that kept tripping up the checks and it was something people like to do.
arccy 14 hours ago [-]
renaming is actually pretty fine, if you don't do stuff like json or text encodings.
only renumbering fields causes problems.
gjvc 11 hours ago [-]
"You're welcome." is such a smug verbal tic.
nullbio 6 hours ago [-]
Protobuf getting LSP support before Codex implements LSPs is wild.
theowaway213456 5 hours ago [-]
What would it mean for codex to "implement LSPs"
nullbio 2 hours ago [-]
LSP server support, like Claude Code does.
PufPufPuf 14 hours ago [-]
Buf does great work at fixing Protobuf to the point of being just barely usable. A godsend if you're stuck with Protobuf/gRPC on a legacy project.
qweqwe14 13 hours ago [-]
What world are you living in where Protobuf/gRPC are considered "legacy"? ..what?
PufPufPuf 23 minutes ago [-]
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't "optimal" but after transfer compression it's not that bad, and the support for JSON Schema is much better across the stacks I use, e.g. Zod in JS/TS, Pydantic in Python, etc. And it's fully usable "by hand" without having the schema, for one-off scripts and such -- compare with Protobuf where you need the full definition to even parse a chunk of data.
antonvs 11 hours ago [-]
In the web dev world, I’ve noticed there are a lot of people who think that JSON is the ultimate modern data format. Typically those same people have barely heard of JSON Schema.
weitendorf 6 hours ago [-]
This has been driving me crazy ever since I started using protobuf/grpc and realized more major tech companies (in the cloud/infra/data world at least, and a lot of other SAAS) were using it or something similar (eg capn proto) internally than not.
It feels like we’re in some sort of deadlock where each of them think “proto/grpc are too niche to support for external users, better just use JSON”, keeping it unfamiliar for an Average Web Developer. But if every company using it just exposed it to third parties/added it to their public APIs, it would immediately be common (and trendy) enough for every web developer to learn it and start using it.
If Google added the missing HTTP/2 streaming support to browsers (blocking native bidi grpc streaming) it would have an instant killer app in making it easier to implement websocket-like client/server applications. It makes absolutely no sense that full duplex bidi was added to the HTTP/2 but remains unimplemented in browsers.
The role MCP, OpenAPI, and JSON schema fill all would be a million times simpler if they were based on protobuf instead of JSON. I can forgive OpenAPI/JSON but it honestly pisses me off that we ended up with MCP and JSON-RPC + JSON schema, and people think these are cool/good tools, and actively adopting them. Just piling on the slop
cdelsolar 9 hours ago [-]
I use Go + Buf + protobuf-es + Connect on my web projects. There is no better stack, I'll die on this hill.
dewey 3 hours ago [-]
This is the way! It's great to just point frontend developers to the Buf documentation for new features and they easily have all the types and generated clients available in their projects too.
sudorandom 2 hours ago [-]
I pushed for us to adopt this setup at my previous company and it was wildly successful. I thought frontend devs would resist but they absolutely loved the generated types and clients. It quickly seemed silly to do anything else.
gafferongames 15 hours ago [-]
While not a direct competitor to protobufs, if you are working in the video game space where struct versioning is not needed, there is an alternative language called "schema" that supports C, C++, C#, Golang, Rust and JavaScript.
Of all names, they pick schema? That's like calling a programming language "language."
max-privatevoid 15 hours ago [-]
My favorite programming language is called "A Programming Language".
andai 15 hours ago [-]
Reminds me of xkcd tattoo that says in Chinese, "It's what my tattoo says."
jayd16 14 hours ago [-]
> video game space where struct versioning is not needed
Save files? Looser than exact version multiplayer?
gafferongames 14 hours ago [-]
Multiplayer games typically deploy both client and server at the same time, and refuse to connect a client if it doesn't speak the exact same protocol as the server.
Thus all the versioning overhead of protobufs is not needed for this wire protocol.
(Yes, games still use versioning everywhere else where it makes sense: save games, asset data, config etc...)
npstr 14 hours ago [-]
Good luck deploying a client to the mobile app stores together with your backend :pain:
But then again, those barely count as games, I guess.
dvtkrlbs 14 hours ago [-]
Wouldn’t it make sense to also have the old version of the game live and gradually roll out the new version for mobile
jayd16 12 hours ago [-]
You can do this but if it's too granular (like you have no concept of version compatibility) then it can heavily split your matchmaking.
Plus the headaches of keeping many out of date builds up to date enough to deploy.
Even if you don't care about in game compatibility, all your servers still talk to some centralized data store and that will likely want a single deploy that handles old clients
cyberax 14 hours ago [-]
We do it just fine (not for games). You submit a new binary for review in advance and then do a coordinated release once the review completes.
jayd16 12 hours ago [-]
Then players are locked out of multiplayer until they download a possibily large content patch.
cyberax 2 hours ago [-]
I think both iOS and Android support separate downloads for large assets?
what 9 hours ago [-]
This feels like normal on mobile? Games force you to update to keep playing.
eventualcomp 13 hours ago [-]
Checked the contributor list, please disclose that you're a primary contributor.
unprovable 13 hours ago [-]
From protobuf to quantum computing, Google just keeps solving problems nobody has...
ventana 13 hours ago [-]
That's not Google. Buf.build is, hilariously enough, a completely separate company that tries to make sense of Google's protobuf, and it's doing a decent job from what I can see.
r_lee 13 hours ago [-]
so you're saying protobuf has no purpose?
booi 12 hours ago [-]
i mean...
teaearlgraycold 12 hours ago [-]
Protobuf should at least get credit for enforcing fields be optional.
debugnik 4 hours ago [-]
They reluctantly acknowledged that as a mistake by adding an actual "optional" modifier for field presence. proto3's previously so-called optional were really all present with a zero default value; proto2 could have supported that for required fields at the code level if they had wanted. In the end, all they've changed is how they frame the feature.
deepsun 5 hours ago [-]
Unpopular opinion -- LSPs are bad because they introduce latency into coding. For every keystroke, my IDE needs to make request/response with LSP, instead of using its own internal parser/colorer/autocomplete.
atiedebee 4 hours ago [-]
You can just not use an LSP? My understanding is that LSPs aren't made to be the fastest (code completion|syntax highlighter|code analysis), but easily integrated into all sorts of IDEs/text editors.
deepsun 58 minutes ago [-]
As far as I understand, IDEs ara way less eager to spend resources onto their own integration if there's an LSP. E.g. last time I tried to code in Zig there was either LSP or nothing.
16 hours ago [-]
aussieguy1234 12 hours ago [-]
I've always thought of protobuf as a Java thing.
It worked great in Java, but not so well in JS, especially with Kafka.
antonvs 11 hours ago [-]
Protobuf was never particularly a Java thing. You could more accurately say it was a C++ thing. It was initially developed in C++, and used mainly in C++ services at Google. The implementation and early ecosystem were C++-centric.
Later, Go became one of the major Protobuf ecosystems, and today it would be understandable to think it was a Go thing.
Storewide 2 hours ago [-]
[flagged]
blackbriar75 9 hours ago [-]
[dead]
ltbarcly3 15 hours ago [-]
Watch as I don't use protobuf because it is horrible.
....
Tada!
If you patch clients to google services in Python to use json instead of grpc they get faster and more reliable. A lot faster. Benchmark it!
For me that is how I know something like protobuf is good. It is a nuisance to manage and distribute the definitions, adds a build step even to languages with no build step normally, is slower than almost every alternative, and artificially restricts you from doing lots of common things. It's so good!
And look at the code quality of the implementation! It's like a team of interns wrote it while drunk. It is a complete spaghetti mess, but has tons of super convoluted micro optimizations that are slower than just doing the most obvious thing, but make the implementation confusing and indirect. It's trash code.
tomtom1337 15 hours ago [-]
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.
throw1234567891 14 hours ago [-]
Json schema?
IshKebab 14 hours ago [-]
I quite like the look of Typespec though I haven't used it much.
I always thought Thrift was waaay better than any of the alternatives, but it always had terrible documentation and I think it died mainly because of that.
ltbarcly3 15 hours ago [-]
The goal is not to have a single source of truth schema. That is a means to some other goal, and it's not even a good means.
If you never change the schema then you don't have to worry about it, get things working and never look back.
If you do change your schema from time to time, you need testing between the two systems. If you have good tests again a single source of truth is fully redundant, both systems are talking just fine. If you don't have tests things can and will break all the time even using protobuf.
afavour 15 hours ago [-]
> The goal is not to have a single source of truth schema. That is a means to some other goal, and it's not even a good means.
It’s about data transmission. Being able to encode and decode in a type safe manner between different languages (and so, different platforms) is a goal that makes a lot of sense.
> If you do change your schema from time to time, you need testing between the two systems
Or you could just use a defined format that doesn’t require testing. I rarely use protobuf but I can see why people do. The guaranteed backwards compatibility is huge for people who can’t just publish a new web frontend at the drop of a hat.
kccqzy 15 hours ago [-]
If you understand how to evolve protobuf schema definitions, then you don’t really need testing. You instinctively know how the parser works when it is parsing data with a different schema from what it expects. And that’s a powerful thing. If your things break even when using protobuf then you don’t grok protobuf.
It’s probably not an exaggeration to say that being able to avoid tests between different systems who have different versions of the schema is a core goal of protobuf. Why? These two different systems are probably owned by different teams, and introducing explicit tests between different versions of them increases coupling between them.
andai 14 hours ago [-]
Both sibling comments say one type of assurance makes the other irrelevant, but I would wager they cover different territory.
onei 15 hours ago [-]
Is that a recent-ish improvement? I feel like HTTP/2 would be roughly the same performance for JSON and protobuf, so maybe this is HTTP/2 vs HTTP/3?
ltbarcly3 15 hours ago [-]
I think the overhead is protobuf itself but I can't check.
pjjpo 11 hours ago [-]
Comparing a wrapped C++ gRPC backed stack with an httpx/requests backed one is like comparing apples to elephants.
okanat 15 hours ago [-]
Protobuf simply encode things way more efficient that JSON can define a single object. You're quite frankly spewing bullshit in this whole thread.
throw1234567891 14 hours ago [-]
You don’t get what they say. It’s not about about how efficient it is after encode, it’s about how fast encode is. They are not spewing bs, they’re focusing on a single point. The question is: do you send it over the wite more often than performing encode/decode.
blanched 14 hours ago [-]
That's what the person you replied to is talking about, and they're right. Putting aside the final byte size (where protobuf also wins), protobuf is faster at both encoding and decoding than json. There are numerous benchmarks you can find that show this.
The advantages of json are not related to performance.
If you're writing JS you cannot beat JSON.parse, because you're running the most optimized C++ implementation of JSON which will outcompete any decoder written JS itself.
Which is not a very generalizable situation.
pastel8739 15 hours ago [-]
Is this because load is lighter on their JSON endpoints that their gRPC ones?
ltbarcly3 15 hours ago [-]
[flagged]
itsthecourier 15 hours ago [-]
so how do you save data over the cable when it's needed?
throw1234567891 14 hours ago [-]
Eventually it’s all bytes. Where do you want to save them?
ltbarcly3 15 hours ago [-]
zstd?? Obviously?
anematode 15 hours ago [-]
JSON. /s
echelon 16 hours ago [-]
Buf's offering of protobuf registries and codegen SDKs for microservices seems less necessary in the LLM era.
I'm starting to question many of protobuf's advantages (perhaps not the wire format). Add to that monorepos and other fads of the 2010s given the rise of LLMs.
I used to be a big believer in this stuff, but I'm quickly having my core assumptions change out from under me.
kristjansson 15 hours ago [-]
A big differentiator is whether one imagines an LLM in-band with most/all future software. If there is, and we’re deferring until very late parts of a program that world have been load bearing, and we’re able to programmatically ands reliably squint and say “eh i know what you meant” … then yeah formalizations seem superfluous-to-counterproductive.
OTOH if LLMs are to write, but not supplant, much of software, then boundaries, delegation to deterministic layers, good compilers to bonk miscreant models on the head with error message seem essential.
At one point it would have been shocking to assert that the compiler would live in-band with the program too. and yet JS eats the world. It seems shocking today that we could have a universal prior over the world operating in the ms/us nJ/pJ range required. And yet … ?
giancarlostoro 16 hours ago [-]
The real argument shouldn't be about protocols becoming obsolete, but programming languages that are "less efficient" could eventually become obsolete in favor of highly scalable and performant languages due to LLMs when the main gap becomes knowing how the tech works at a high level, and not the syntax, why code in one language over another if you don't need to worry about messing up on syntax, only about reviewing logic for sanity and correctness against business rules as well as validating that it is stable code.
cyberax 15 hours ago [-]
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 too restricting.
And the best thing is that it's compact, compared to OpenAPI.
ragall 6 hours ago [-]
You're wrong on every count: given the small context window of LLMs, the need for interfaces and scehmas is even greater.
sudorandom 16 hours ago [-]
I feel exactly that way about REST. The assumption that LLMs make schemas obsolete misses how structured outputs actually work in production. When you have probabilistic models generating code, strict contracts become more critical, not less. It is no coincidence that several major LLM platforms rely on ConnectRPC and Protobuf for their own APIs.
echelon 16 hours ago [-]
You're right, but the adeptness of models to spin up clients and behaviors on the fly is remarkable. They're capturing the semantics of behavior at a deeper level.
If we do strict schemas, I'd like to see less ceremony around them. Tool calls instead of brittle build steps and protocol registries.
Perhaps we need new tools for this going forward.
sudorandom 16 hours ago [-]
Hm... Maybe. In my view, an IDL is part of the input that you absolutely want humans to author or carefully review at least. In my experience, the ceremony around generating code is also performed very well by LLMs. But I do agree, there's definitely some changes that are needed to integrate Protobufs better. Some languages have built-in tooling to make it seamless, but it's definitely not universal.
someothherguyy 10 hours ago [-]
why? are humans going to stop using services?
yodsanklai 1 hours ago [-]
Aren't LSP dying (and eventually IDE, at least in their current form) as everybody use LLM to code. I know some big tech companies redirected teams supporting them to new efforts (ie. tool integration with AI).
Weird post. I built IntelliJ protobuf support [1] while at Google like 10 years ago, and it started shipping by default with IntelliJ in ~2021. Maybe that's not considered "modern".
[1] https://github.com/jvolkman/intellij-protobuf-editor
It's a bit odd for the parent commenter to say "Weird post" and implying that having an editor specific feature would somehow make having an LSP that works for everyone be any less interesting.
Probably the author
It can be hard for some people to navigate the nuances between usage of a tongue-in-cheek usage of the phrase which is more socially acceptable or humorous from the version that reads as arrogant
Test for yourself: next time you take out the garbage, loudly tell your partner or roommate, “I took out the garbage. You’re welcome.”
Try this instead: give a stranger a piece of pre-chewed gum and say “you’re welcome!” Hell, even if it’s not pre-chewed, it’s just presumptuous and rude. You have no idea if they value it or not. They might not even like it.
Even if my barista handed me the coffee I ordered and said “you’re welcome” before I thanked them first, I’d think they’re a little off kilter.
Coming off more as projecting. Maybe you're being an asshole when you say "You're welcome" but it's a bit how the guy who steals is the first one to accuse others of theft.
Try my experiments yourself if you disagree, and come back and let us all know how they went for you.
Of course it's poor taste to add the "You're welcome". But poor taste is par for the course for such startup, unfortunately.
I also read the title as having an air of self-importance or maybe passive-aggression. If you read it a little more dispassionately then it's just an awkward way of stating that this is a gift.
Why is this a gift? The company does not need to give it to you, though it arguably benefits from doing so. It did so with some definition of "free."
It is definitely best to reuse the parser for the runtime when implementing an LSP but to do so properly means implementing the parser itself as a standalone library. Even better is shipping the semantic analysis as well!
Implementation drift is definitely an issue.
But great project anyways, just wanted to put my thoughts on the matter into the conversation!
A language parser should be correct. A LSP parser should be fault tolerant. My understanding is you cant have both.
Having built a lot of protobuf tooling, I'd estimate that protobuf largely falls into the former camp; most of your time working with .proto files is operating on fields which terminate using `;` at the end of the line (though multi-line is also possible).
[1] source: I've done it for SQLite SQL at https://github.com/LalitMaganti/syntaqlite/
[2] e.g. SQL naturally has this at statement and expression boundaries which covers almost all of the cases people care about.
Many editors use tree-sitter, but that is separate from the LSP.
That said, proto itself dissuades or forbids the kind of common things you might do with a LSP, such as renaming.
Renaming fields is a big no-no [edit: this isn't true, see corrections below], as is doing things like re-ordering fields.
A core idea of proto is that versions are strictly compatible with with previous versions. This itself has limitations and challenges for migrations, but encourages good practice about compatibility that usually gets ignored or hand-waved away in most ecosystems.
I accept however that it's often easy to offload both the re-structuring and the checking of version compatibility to an LLM and let them go at it.
Reordering fields without changing their ID is indeed a non-breaking change from what I understand, albeit quite a useless one :)
If you have a (long) list of fields and you want to keep them lexicographically sorted, being able to reorder is quite useful if you rename a field.
There was definitely one that kept tripping up the checks and it was something people like to do.
JSON isn't "optimal" but after transfer compression it's not that bad, and the support for JSON Schema is much better across the stacks I use, e.g. Zod in JS/TS, Pydantic in Python, etc. And it's fully usable "by hand" without having the schema, for one-off scripts and such -- compare with Protobuf where you need the full definition to even parse a chunk of data.
It feels like we’re in some sort of deadlock where each of them think “proto/grpc are too niche to support for external users, better just use JSON”, keeping it unfamiliar for an Average Web Developer. But if every company using it just exposed it to third parties/added it to their public APIs, it would immediately be common (and trendy) enough for every web developer to learn it and start using it.
If Google added the missing HTTP/2 streaming support to browsers (blocking native bidi grpc streaming) it would have an instant killer app in making it easier to implement websocket-like client/server applications. It makes absolutely no sense that full duplex bidi was added to the HTTP/2 but remains unimplemented in browsers.
The role MCP, OpenAPI, and JSON schema fill all would be a million times simpler if they were based on protobuf instead of JSON. I can forgive OpenAPI/JSON but it honestly pisses me off that we ended up with MCP and JSON-RPC + JSON schema, and people think these are cool/good tools, and actively adopting them. Just piling on the slop
https://github.com/mas-bandwidth/schema
Save files? Looser than exact version multiplayer?
Thus all the versioning overhead of protobufs is not needed for this wire protocol.
(Yes, games still use versioning everywhere else where it makes sense: save games, asset data, config etc...)
But then again, those barely count as games, I guess.
Plus the headaches of keeping many out of date builds up to date enough to deploy.
Even if you don't care about in game compatibility, all your servers still talk to some centralized data store and that will likely want a single deploy that handles old clients
It worked great in Java, but not so well in JS, especially with Kafka.
Later, Go became one of the major Protobuf ecosystems, and today it would be understandable to think it was a Go thing.
....
Tada!
If you patch clients to google services in Python to use json instead of grpc they get faster and more reliable. A lot faster. Benchmark it!
For me that is how I know something like protobuf is good. It is a nuisance to manage and distribute the definitions, adds a build step even to languages with no build step normally, is slower than almost every alternative, and artificially restricts you from doing lots of common things. It's so good!And look at the code quality of the implementation! It's like a team of interns wrote it while drunk. It is a complete spaghetti mess, but has tons of super convoluted micro optimizations that are slower than just doing the most obvious thing, but make the implementation confusing and indirect. It's trash code.
I always thought Thrift was waaay better than any of the alternatives, but it always had terrible documentation and I think it died mainly because of that.
If you never change the schema then you don't have to worry about it, get things working and never look back.
If you do change your schema from time to time, you need testing between the two systems. If you have good tests again a single source of truth is fully redundant, both systems are talking just fine. If you don't have tests things can and will break all the time even using protobuf.
It’s about data transmission. Being able to encode and decode in a type safe manner between different languages (and so, different platforms) is a goal that makes a lot of sense.
> If you do change your schema from time to time, you need testing between the two systems
Or you could just use a defined format that doesn’t require testing. I rarely use protobuf but I can see why people do. The guaranteed backwards compatibility is huge for people who can’t just publish a new web frontend at the drop of a hat.
It’s probably not an exaggeration to say that being able to avoid tests between different systems who have different versions of the schema is a core goal of protobuf. Why? These two different systems are probably owned by different teams, and introducing explicit tests between different versions of them increases coupling between them.
The advantages of json are not related to performance.
Which is not a very generalizable situation.
I'm starting to question many of protobuf's advantages (perhaps not the wire format). Add to that monorepos and other fads of the 2010s given the rise of LLMs.
I used to be a big believer in this stuff, but I'm quickly having my core assumptions change out from under me.
OTOH if LLMs are to write, but not supplant, much of software, then boundaries, delegation to deterministic layers, good compilers to bonk miscreant models on the head with error message seem essential.
At one point it would have been shocking to assert that the compiler would live in-band with the program too. and yet JS eats the world. It seems shocking today that we could have a universal prior over the world operating in the ms/us nJ/pJ range required. And yet … ?
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 too restricting.
And the best thing is that it's compact, compared to OpenAPI.
If we do strict schemas, I'd like to see less ceremony around them. Tool calls instead of brittle build steps and protocol registries.
Perhaps we need new tools for this going forward.