Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • 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.

    by aussieguy1234
  • 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
  • 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
  • Protobuf getting LSP support before Codex implements LSPs is wild.
    by nullbio
  • What would it mean for codex to "implement LSPs"
    by theowaway213456
  • buf also has an interesting dynamic protobuf parser that's a drop-in for dynamicpb https://github.com/bufbuild/hyperpb-go
    by loicalleyne
  • "You're welcome." is such a smug verbal tic.
    by gjvc
  • 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.

    https://github.com/mas-bandwidth/schema

    by gafferongames
  • 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
  • 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 same
    by 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!

    by williamcotton
  • 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
  • What can I say, except you're welcome.
    by hinkley
  • It's gotten out of hand. Companies making money think they do everyone a favor.
    by bmitc
  • 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-server
    by alecthomas
  • The difference is that Buf's LSP is fully spec-complete since it's built on the same tooling that powers the buf CLI. I've seen several attempts at Protobuf LSPs over the years, but none that actually conform to the Protobuf specification, including the one you linked. That project is built on `emicklei/proto`, which readily accepts broken Protobuf and always has. The author says so in the README: "Current parser implementation is not completely validating .proto definitions." Maybe Buf should update the headline to "Protobuf finally has LSP support that works."
    by sudorandom
  • 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
  • > 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".

    [1] https://github.com/jvolkman/intellij-protobuf-editor

    by jvolkman
  • "IntelliJ is for Java, and Java is legacy!"

    Probably the author

    by brunoborges