Hacker News Reader

Comment by eterm | Hacker News Reader

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.

View on HN

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

Considered breaking change because JSON serialization will change, and JSON is used quite often.

Reordering fields without changing their ID is indeed a non-breaking change from what I understand, albeit quite a useless one :)

> a useless one

If you have a (long) list of fields and you want to keep them lexicographically sorted, being able to reorder is quite useful if you rename a field.

Renaming is forbidden though (because JSON and textproto). In Google, it's a documented antipattern to try to make protobuf look "nice" by changing field indices, rearranging fields, etc. — the common ground is that it's better to not do it.

As long as you know the use cases of your fields, renaming is just fine. My team regularly does it. We also maintain our own serializer and deserializer json, XML, and fixed with formats. The json one we handle serialization using an annotation to say how it should be exported.

Of course, the whole concept of a breaking change does not really apply if all usage is within the controlled code. The problems start to appear when you have external users with old versions; then protobuf starts having a bunch of weird limitations. My favorite is that it's forbidden to move a field into or out of a `oneof`: it's a compatible change in a sense of wire format and JSON, but breaks the generated Golang code.

Breaking changes matter even with controlled code, because you can have requests that straddle upgrade boundaries, it's fiction to believe that all services are upgraded at the same moment, and pretending that is the case is the sort of thing that leads to quiet data corruption or mysterious bugs that can never seem to get reproduced.

Even if you upgrade with coordinated downtime across your entire service stack ( a bit old-school, but still happens more than you might imagine. ), then you still have to occasionally deal with requests that get persisted somewhere, possibly for support purposes, and it's much handier if the wire format remains compatible, at least between immediate versions.

There is a lot of ambiguity in this thread.

Yes, breaking changes need to be staged carefully/compatibly across versions.

Simple renaming/reordering is not a breaking change between code versions. The wire format knows numeric ids, not names. It breaks code compilation until the renames are put into effect. There is a subtle breakage where someone renames a field (think: field -> old_field) and then later adds "field" to mean something else; software that isn't recompiled in this window might not recognize that "field" is potentially different. Uncompiled languages may suffer this even more subtly. -- All of this to say, breaking compilation is not the end of the world but there are more dragons as the scope grows.

Stop-the-world is usually only needed when someone has made an unplanned/incompatible change with versions that are still running. If your infrastructure+development is done right (hah) this should never happen.

Depends, if you use textproto then renaming is problematic too

Shit, you're right, I'm trying to remember the one that used to trip us up all the time, maybe it was removing fields?

There was definitely one that kept tripping up the checks and it was something people like to do.

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

Reply on news.ycombinator.com