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".
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
> Edit: In full transparency, this blog post was originally titled "Protobuf finally has LSP support. You're Welcome." We thought this might generate some interest, but unfortunately this post sat unloved for months. Then, out of the blue, this post decided to make front page HN, and we received some choice feedback on our use of "You're Welcome" and our poor comedic abilities. Fair enough, we appreciate you speaking up - and we of course *thank you* for your continued support of our work!
I, personally, enjoy Buf. It has solved many frustrations I've had with The Way it was previously done, manually installing protoc plugins, writing arcane flags into scripts nobody wants to touch, working around various quirks, like how protoc produces different output based on which directory you invoke it in, et cetera... I don't quite like the remote plugin model and rate limiting, but using local plugins is easy enough that it doesn't matter.
Buf has made my life easier, and I've actually been using `buf_ls` for a while now in NeoVim. I understand where the criticism of the title comes from, but I don't personally feel it in this particular case. In fact, I didn't even notice it.
I don't even mind the monetized properietary cloud thing, as long as Buf CLI and the related toolchain remains free software, serving the community. Hope you won't do the ol' switcharoo any time soon.
And the Buf CLI will always be free and OSS, don't worry!
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.
> 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.
Jeez...
But also that's a conversation where you can thank them first. That part isn't applicable to a post like this.
If this doesn't make sense to you, I'm not sure there's much anyone can do to convince you, because it's purely social convention. It's certainly possible that the author didn't realize it either, but having to deal with reactions about word choice when putting out writing explicitly for public consumption kinda comes with the territory.
This goes for Hacker News comments too of course, but as someone with no horse in this race, your interference about their word choice seems like much more of a stretch than theirs about the author. Not recognizing that a title to a blog post will evoke a negative reactions in a lot of readers does genuinely seem like information about the author socially in a way that having that common negative reaction does not.
The social convention is for conversations.
You seem incredulous at the idea that some things that might be socially acceptable in conversational circumstances would not be perceived similarly in published writing, but I don't really understand why. There are all sorts of things that might not cause someone to bat an eye in a spoken conversation that are much more difficult to use in writing.
I don't think we're going to resolve this difference in view.
But please stop making wild guesses about how I handle broad categories of communication when I'm commenting on one specific case. I don't say it doesn't make sense. I'm not incredulous. That's really obnoxious.
> The social convention is for conversations.
> How is a thank you supposed to precede it in a blog post?
That's a pretty clear distinction between a blog post and conversations.
Now you're saying:
> But please stop making wild guesses about how I handle broad categories of communication when I'm commenting on one specific case. I don't say it doesn't make sense. I'm not incredulous. That's really obnoxious.
I honestly have no clue what you're even trying to say at this point. You don't seem to want to say it directly, and yet you're now claiming I'm being obnoxious for trying to figure it out.
> I don't think we're going to resolve this difference in view.
That's the one thing we can agree on, since from my perspective, you're being a lot more obnoxious by pretty much treating people the exact same way you've been complaining about the entire time.
I have been very direct. You're trying to make it more indirect when you try to generalize like this. And throwing out "if this doesn't make sense to you", or "you seem incredulous" about the entire existence of certain social norms that apply in some situations but not others, is a bad way of trying to figure out what I mean; it's rude.
Edit: An analogy: I have a critique about a type of waffle and you imply I don't understand the purpose of baked goods in general. This is not a good way to converse and the confusion is not my fault.
I don't think you've been direct at all about anything relating to the actual original conversation; the only things you've been direct about are in telling me or others that we're wrong and pointing out the things you think we've been doing wrong (along with a random assumption about someone else's life based on the comment they initially made), and then proceeded to take issue with every instance where someone else does the exact same things.
It's pretty much impossible phrase this point because you have gotten upset any time I happen to incidentally phrase something using the second person pronoun, but I'll try my best: when person A says something, and person B doesn't understand it, that's not sufficient evidence to conclude that person A or person B is at fault. Communication doesn't exist in only one direction. Sometimes it might be because person B did a bad job understanding, but sometimes it's also because person A did a bad job communicating. In the scenarios where person A happened to do a bad job, it's pretty common for them not to realize, because if they did realize, they would follow up by clarifying. It's pretty much impossible for person A to know whether they communicated clearly or not without some other person to interpret it, because communication that isn't interpreted in some way by someone else isn't actually communication.
This is so far away from anything I meant to say that I have no idea what happened.
> you've still refused to elaborate on how or why you think they're different
I don't?
I think blog posts are different from conversations but that should be self-explanatory.
> along with a random assumption about someone else's life based on the comment they initially made
"Bad day or something" is suggesting they're being too harsh. It's not suggesting they fail to understand the situation, the way you did with me.
> I don't think you've been direct at all about anything relating to the actual original conversation; the only things you've been direct about are in telling me or others that we're wrong and pointing out the things you think we've been doing wrong
What do you want me to be more direct about? The answer to whether I understand these broad categories of social norms exist is yes. I just don't think the blog post falls into the category where you need a thank you first. Is there anything else you want to ask?
I don't think I can say anything useful about your last paragraph.
Looking back though before writing this comment, I did notice that the comment seems to have been flagged, and that doesn't seem necessary to me. On the off chance that it might have been a factor in your subsequent responses, I went ahead and vouched for it because I think I would be frustrated if I were flagged for a comment that was similarly benign (even if it was wrong).
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.
Even if you upgrade with coordinated downtime across your entire service stack ( a bit old-school, but still happens more than you might imagine. ), then you still have to occasionally deal with requests that get persisted somewhere, possibly for support purposes, and it's much handier if the wire format remains compatible, at least between immediate versions.
Yes, breaking changes need to be staged carefully/compatibly across versions.
Simple renaming/reordering is not a breaking change between code versions. The wire format knows numeric ids, not names. It breaks code compilation until the renames are put into effect. There is a subtle breakage where someone renames a field (think: field -> old_field) and then later adds "field" to mean something else; software that isn't recompiled in this window might not recognize that "field" is potentially different. Uncompiled languages may suffer this even more subtly. -- All of this to say, breaking compilation is not the end of the world but there are more dragons as the scope grows.
Stop-the-world is usually only needed when someone has made an unplanned/incompatible change with versions that are still running. If your infrastructure+development is done right (hah) this should never happen.
There was definitely one that kept tripping up the checks and it was something people like to do.
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
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
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.
Even my little chromebook can provide completions and errors effectively instantly to me, even in medium sized rust projects.
Or are you saying (probably maximum) ~20ms delay is blocking your ability to code?
96GB RAM, 12 vCPU, Linux, desktop.
....
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!
def get_json_client() -> CloudLoggingQueryClient:
"""Client for log queries (JSON transport, avoids gRPC overhead)."""
client = google.cloud.logging.Client.from_service_account_info(...)
client._use_grpc = False
return client
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.
Protobuf only allows you to add optional fields after the initial version, right? Because otherwise it would not be backwards compatible. Protobuf does not allow you to define contingent logic between fields. Optional fields are always nullable (or you must provide a default). This forces you to know all of this and use a method to see if it was actually set or just defaulted. So you have a ton of nullable/defaulted fields that likely are required to be filled in or not filled in, contingent on other values in the same struct. For example if the charge type is "purchase" then price must be not null and > 0. That sort of thing. This is so common you should just assume your app has a million little rules like this that are assumed. Protobuf does not help you here at all. You need some other logic to validate the data on top of protobuf. once you have that anyway protobuf's value is that it's expensive, requires build steps, is actually not fast, and forces you to distribute the schema between different apps somehow.
If it's not obvious yet, lets say you are sending your charge structs and you have a bug where sometimes you don't set price. It's defaulted to 0 or -1 or whatever nonsense value the default is, or null, it doesn't matter it's not correct sometimes. That is why you need tests my guy. Protobuf can't fix this. If you use json the tests make sure everything protobuf does for you is done too. In a world where you have to write tests because protobuf can't force you to correctly set fields, you have tests already, and protobuf didn't help you at all. Whether you call it tests or input validation or whatever, protobuf definitions are insufficient, and when you have what is sufficient it 100% covers everything protobuf does 'for you'.
If you don't get it at this point then lets just agree that you will never get it.
That’s not all. For example, you can also change fields from optional to repeated or vice versa. For another example, you can also delete fields.
> Protobuf does not allow you to define contingent logic between fields.
You are just saying that protobuf is not a data validation library. That’s true; it only handles data serialization. You need to write validations yourself. And you will most likely need tests to test your validation code. But those are entirely tests within a single process; they are not tests involving a producer and a consumer of a protobuf message, which is the wrong kind of tests.
> For example if the charge type is "purchase" then price must be not null and > 0. That sort of thing.
That sort of thing sounds like you are not using `oneof` appropriately. The charge type shouldn’t be a field. It should be a submessage called Purchase.
The advantages of json are not related to performance.
Which is not a very generalizable situation.
The comparison that's being made is equivalent to implementing quick sort in Python and bubble sort in C++ and then declaring bubble sort is the better alternative.
Anyone with a healthy understading of computer science and programming experience will not make bullshit claims like that.
Which link were you comparing FFI in python to json in python? The link I see seems to be about pure JavaScript language Protobuf impls vs json.parse?
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.
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.
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 … ?
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.