Protobuf has LSP support

Original Article ↗ Hacker News Discussion ↗

Protobuf’s new language server protocol (LSP) support from Buf is prompting renewed scrutiny of both the format and its tooling, especially compared with JSON, REST, and emerging LLM-driven workflows. Commenters debate whether strict schemas and IDLs like Protobuf are becoming less necessary or more critical in a world of probabilistic models, citing trade-offs in performance, ergonomics, versioning, and multi-language interoperability. The launch also raises questions about LSPs versus IDE-specific integrations, prior Protobuf editor support, and even the tone of corporate open-source announcements.

Role of Protobuf and Schemas in the LLM Era

  • Some argue LLMs reduce the need for heavy schema tooling, monorepos, and protobuf-centric microservice infrastructure.
  • Others strongly disagree, claiming probabilistic code generation makes strict, shared contracts more important.
  • Divergence hinges on whether future systems keep LLMs “in-band” for behavior or treat them as helpers that still hand off to deterministic, well-typed layers.

Protobuf vs JSON: Performance and Practicality

  • One camp reports gRPC/protobuf being slower and less reliable than JSON for some Google Cloud Python clients, criticizing protobuf’s complexity, build steps, and ergonomics.
  • Others insist protobuf is generally faster and more compact on the wire and that JSON’s advantages are usability and ubiquity, not performance.
  • Several note ecosystem-specific caveats: highly optimized JSON implementations in JS and weak protobuf implementations in Python can reverse expected performance claims.

Schemas, Versioning, and Testing

  • Supporters value protobuf for language-agnostic, type-safe data interchange and backward-compatible evolution rules.
  • Some claim if you “understand protobuf” you can often avoid cross-system tests because schema evolution behavior is predictable.
  • Critics argue you still need validation and tests for business logic (e.g., field interdependencies), so protobuf doesn’t remove the real sources of breakage.
  • Clarifications: renaming and reordering fields is wire-compatible as long as field numbers and types stay; renumbering or moving fields into/out of oneofs can be problematic, especially with JSON/text formats or specific language generators.

Buf’s LSP and Parsing Approach

  • Buf’s LSP is integrated as a buf lsp serve subcommand, built on the same parser/compiler that powers the CLI.
  • Some see this as the first spec-complete, robust protobuf LSP; earlier ones are criticized for accepting invalid proto or lacking full validation.
  • Debate over LSP implementation: reuse the “real” language parser vs separate, fault-tolerant parsers (tree-sitter or custom). Opinions differ on whether correctness and error recovery can coexist in a single parser.

LSPs, IDEs, and Developer Experience

  • Some say protobuf already had good IDE support (e.g., IntelliJ plugins), questioning claims of “first modern” support.
  • Others argue LSP-based tooling is more “modern” due to editor-agnostic integration, even if deep IDE plugins can be more powerful.
  • A minority complains that LSPs introduce noticeable latency; others find delays negligible.
  • There’s speculation that LSPs/IDEs may become less central as LLM-based coding tools advance, but this remains contested.

Tone of the Blog Post

  • The original “You’re welcome” phrasing in the post title is widely perceived as arrogant or awkward; a few readers find the backlash overblown.
  • The company later acknowledges the misstep, changes the title, and adds an edit explaining the intent and feedback.