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.

It's gotten out of hand. Companies making money think they do everyone a favor.

Your HN comment has a reply. You're welcome.

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.

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.

buf is a parser / compiler as an alternative to protoc https://buf.build/docs/migration-guides/migrate-from-protoc/

Actually renaming and reordering fields is completely fine, as long as the field ID and type stay the same

renaming is actually pretty fine, if you don't do stuff like json or text encodings. only renumbering fields causes problems.

That's not Google. Buf.build is, hilariously enough, a completely separate company that tries to make sense of Google's protobuf, and it's doing a decent job from what I can see.

so you're saying protobuf has no purpose?

Protobuf should at least get credit for enforcing fields be optional.

What world are you living in where Protobuf/gRPC are considered "legacy"? ..what?

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.

Of all names, they pick schema? That's like calling a programming language "language."

> video game space where struct versioning is not needed

Save files? Looser than exact version multiplayer?

Checked the contributor list, please disclose that you're a primary contributor.

What are good alternatives when you need a common "single source of truth" schema shared between multiple languages? We use protobuf between c# and Python.

Is that a recent-ish improvement? I feel like HTTP/2 would be roughly the same performance for JSON and protobuf, so maybe this is HTTP/2 vs HTTP/3?

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

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

A big differentiator is whether one imagines an LLM in-band with most/all future software. If there is, and we’re deferring until very late parts of a program that world have been load bearing, and we’re able to programmatically ands reliably squint and say “eh i know what you meant” … then yeah formalizations seem superfluous-to-counterproductive.

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 … ?

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.

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.

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.