Hacker News

Protobuf has LSP support. You're welcome

36 points by theanonymousone 2 hours ago | 10 comments

ltbarcly3 10 minutes 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!

  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

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 constant, super convoluted micro optimizations that are slower than just doing the most obvious thing. It's trash code.

pastel8739 53 seconds ago

Is this because load is lighter on their JSON endpoints that their gRPC ones?

itsthecourier 5 minutes ago

so how do you save data over the cable when it's needed?

anematode 4 minutes ago

JSON. /s

echelon 2 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.

giancarlostoro 13 minutes 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 12 minutes 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.

sudorandom 58 minutes 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 55 minutes 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 50 minutes 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.