sudorandom

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."

I pushed for us to adopt this setup at my previous company and it was wildly successful. I thought frontend devs would resist but they absolutely loved the generated types and clients. It quickly seemed silly to do anything else.

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.

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.

The buf CLI can do this.

Here's how it looks to convert from encoded protobuf to json (protojson).

  buf convert schema.proto \
    --type YourMessageName \
    --from payload.binpb \
    --to output.json

And just invert the arguments to convert back.

  buf convert schema.proto \
    --type YourMessageName \
    --from data.json \
    --to encoded.binpb

You should really check out ConnectRPC. Out of the box it supports gRPC, gRPC-Web and a much more reasonable protocol called Connect without an extra middleware to do translation between gRPC/gRPC-Web. Plus, their typescript support is very well supported and there is a library exposing a Tanstack Query wrapper.

They are the protobuf descriptors, which is basically the protobuf encoded version of the protobuf files. They can be optional and many plugins have options to exclude that part from the generated code. Generally, they're useful for the Server Reflection feature of gRPC and it's used for runtime reflection.

Here's a more complete description of what they are and how they're used: https://buf.build/docs/reference/descriptors.

This is probably not exhaustive but I think these frameworks can support HTTP/3 today:

- The standard grpc library for C#, dotnet-grpc

- It may already be possible in rust with Tonic with the Hyper http transport

- It's possible in Go if you use ConnectRPC with quic-go

- This is untested but I believe many gRPC-Web implementations in the browser might "just work" with HTTP/3 as well as long as the browsers are informed of the support via the "ALT-SVC" header and the servers supports it.

Hey, author here:

> Why does gRPC have to use such a non-standard term for this that only mathematicians have an intuitive understanding of? I have to explain the term every time I use it.

>> Who are you working with lol? Nobody I’ve worked with has struggled with this concept, and I’ve worked with a range of devs, including very junior and non-native-English speakers.

This is just a small complaint. It's super easy to explain what unary means but it's often infinitely easier to use a standard industry term and not explain anything.

>> Also, it doesn’t pass my “send a friend a cURL example” test for any web API.

> Well yeah. It’s not really intended for that use-case?

Yeah, I agree. Being easy to use isn't the indented use-case for gRPC.

>> The reliance on HTTP/2 initially limited gRPC’s reach, as not all platforms and browsers fully supported it

> Again, not the intended use-case. Where does this web-browsers-are-the-be-all-and-of-tech attitude come from? Not everything needs to be based around browser support. I do agree on http/3 support lacking though.

I did say browsers here but the "platform" I am thinking of right now is actually Unity, since I do work in the game industry. Unity doesn't have support for HTTP/2. It seems that I have different experiences than you, but I still think this point is valid. gRPC didn't need to be completely broken on HTTP/1.1.

>> lack of a standardized JSON mapping

> Because JSON has an extremely anaemic set of types that either fail to encode the same semantics, or require all sorts of extra verbosity to encode. I have the opposite experience with protobuf: I know the schema, so I know what I expect to get valid data, I don’t need to rely on “look at the json to see if I got the field capitalisation right”.

I agree that it's much easier to stick to protobuf once you're completely bought-in but not every project is greenfield. Before a well-defined JSON mapping and tooling that adhered to it is is very hard to transition from JSON to protobuf. Now it's a lot easier.

>> It has made gRPC less accessible for developers accustomed to JSON-based APIs

> Because god forbid they ever had to learn anything new right? Nope, better for the rest of us to just constantly bend over backwards to support the darlings who “only know json” and apparently can’t learn anything else, ever.

No comment. I think we just have different approaches to teaching.

>> Only google would think not solving dependency management is the solution to dependency management

> Extremely good point. Will definitely be looking at Buf the next time I touch GRPC things.

I'm glad to hear it! I've had nothing but execellent experiences with buf tooling and their employees.

> GRPC is a lower-overhead, binary rpc for server-to-server or client-server use cases that want better performance and faster integration that a shared schema/IDL permits. Being able to drop in some proto files and automatically have a package with the methods available and not having to spend time wiring up url’s and writing types and parsing logic is amazing. Sorry it’s not a good fit for serving your webpage, criticising it for not being good at web stuff is like blaming a tank for not winning street races.

Without looping in the frontend (aka web) it makes the contract-based philosophy of gRPC much less compelling. Because without that, you would have to have a completely different language for contracts between service-to-service (protobuf) than frontend to service (maybe OpenAPI). For the record: I very much prefer protobufs for the "contract source of truth" to OpenAPI. gRPC-Web exists because people wanted to make this work but they built their street racer with some tank parts.

> GRPC isn’t without its issues and shortcomings- I’d like to see better enums and a stronger type system, and defs http/3 or raw quic transport.

Totally agree!

Author here: Sorry that I was so harsh on textproto. You are right that it has some strengths over JSON... I'm actually a fan of JSONC for this reason. It does limit you on tooling... but so does textproto, right?

I think the bigger thing that I'm worried about is that gRPC has so many mandatory features that it can become hard to make a good implementation in new languages. To be honest there are some languages where the gRPC implementation is just not great and I blame the feature bloat... and I think textproto was a good demonstration of that feature bloat to me.

Author here: I definitely should have been more explicit for my love of connectrpc, buf, protovalidate, etc. I do mention ConnectRPC but maybe not as loud as I could have. I definitely try to avoid confessing my love for ConnectRPC in every post, but sometimes it's hard not to because they've made such good strategic decisions that just make sense and round out the ecosystem so well.

Author here: it's nerdy web trivia but HTTP trailers are actually in the HTTP/1.1 spec, although very few browsers, load balancers, programming languages, etc. implemented it at the time since it wasn't super useful for the web. You are definitely correct that it is an exotic feature that often gets forgotten about.

This hasn't been my experience... You can also set that value using an environmental variable (GOMAXPROCS). You might want to make sure that isn't set in your environment. Otherwise, you might be experiencing a bug that you should probably report.

Reference: https://golang.org/doc/go1.5

    Golang: to enable all the cores, you have to put in your code runtime.GOMAXPROCS(num of cores you want to use)

This is no longer true. With Go 1.5 and higher GOMAXPROCS is set to the number of CPUs available by default.

github: sudorandom

To be honest, the overall market effects were trivial. The one thing that did happen was the actual trade that happened in and out of Jita (the biggest trade hub in the game) was virtually stopped as the volume of trade for raw materials pretty much stopped. The amount of transport ships reduced to a relatively tiny amount.

Despite all that, there are a number of reasons that this won't have a big impact overall. The thing only lasted for 3 days. Lots of people will just go someone else to buy their stuff (there are several other trade hubs in the game) or will just not buy stuff those days. Another reason is that this event was announced months in advance. Many people stocked up on the things they need to keep their personal industrial machine running. I suspect the incursion would need to continue for at least a couple weeks before you see any sort of market crash. Plus, there are always other places to go. That trade hub would die in a sense, but that might only marginally affect the overall economy.