Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- I've always thought of protobuf as a Java thing.
It worked great in Java, but not so well in JS, especially with Kafka.
- 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.
by antonvs - 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.by deepsun
- Maybe if you have an extremely slow computer?
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?
by chlorion - 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.by atiedebee
- LSP isn't used for syntax highlights usually, that's still the job of the editor. This is where something like treesitter usually comes in. LSP is only used in this case for errors/annotations/etc.by ecnahc515
- 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.by PufPufPuf
- What world are you living in where Protobuf/gRPC are considered "legacy"? ..what?by qweqwe14
- 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.
- Checked the contributor list, please disclose that you're a primary contributor.by eventualcomp
- > video game space where struct versioning is not needed
Save files? Looser than exact version multiplayer?
by jayd16 - Of all names, they pick schema? That's like calling a programming language "language."by satvikpendem
- Protobuf getting LSP support before Codex implements LSPs is wild.by nullbio
- What would it mean for codex to "implement LSPs"
- "You're welcome." is such a smug verbal tic.by gjvc
- 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.
by eterm - renaming is actually pretty fine, if you don't do stuff like json or text encodings. only renumbering fields causes problems.by arccy
- Actually renaming and reordering fields is completely fine, as long as the field ID and type stay the sameby wazzaps
- 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!
- buf is a parser / compiler as an alternative to protoc https://buf.build/docs/migration-guides/migrate-from-protoc/by arccy
- 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.by adastra22
- 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.
by vyaa - "You're welcome" is absolutely hilarious to read from a company post.by lacoolj
- We're terrible comedians - we've added something of a mea culpa to the post!by bufbuild
- Wow 18 hours in and they haven't changed the title of their post. What jerks.by zeafoamrun
- It's gotten out of hand. Companies making money think they do everyone a favor.by bmitc
- What can I say, except you're welcome.by hinkley
- Your HN comment has a reply. You're welcome.by trial3
- What an oddly arrogant post, there's been a Protobuf LSP available for years: https://github.com/lasorda/protobuf-language-serverby alecthomas
- 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.by llm_nerd