> Minor thing that bothered me disproportionately: the constant syntax in the docs (x = 600) doesn't match what the parser actually accepts (x: 600).
You’re a better man than me. If the docs can’t even get the syntax right, that’s a hard no from me.
Also, fwiw, you’ve got a few points wrong about protos. Inspecting the binary data is hard, but the tag numbers are present. You need the schema, but at least you can identify each element.
Also, I disagree on the constructor front. Proto forces you to grapple with the reality that a field may be missing. In a production system, when adding a new field, there will be a point where that field isn’t present on only one side of the network call. The compiler isn’t saving you.
Fresh is more honest than better, and personally, I wouldn’t change it.
> Also, I disagree on the constructor front. Proto forces you to grapple with the reality that a field may be missing. In a production system, when adding a new field, there will be a point where that field isn’t present on only one side of the network call. The compiler isn’t saving you.
I agree it's important for users to understand that newer fields won't be set when they deserialize old data -- whether that's with Protobuf or Skir. I disagree with the idea that not forcing you to update all constructor call sites when you add a field will help (significantly) with that. Are you saying that because Protobuf forces you to manually search for all call sites when you add a field, it forces you to think about what happens if the field is not set at deserialization, hence, it's a good thing? I'm not sure that outweighs the cost of bugs introduced by cases where you forget to update a constructor call site when you add a field to your schema.
Respectfully, I’ve never forgotten a call site, but also yes. In a hypothetical HelloWorld service, the HelloRequest and HelloResponse generally aren’t used anywhere except a rpc caller and rpc handler, so it’s not hard to “remember” and find the usage.
Some callers may not need to update right away, or don’t need the new feature at all, and breaking the existing callers compilation is bad. If your caller is a different team, for example, and their CICD breaks because you added a field, that’s bad. Each place it’s used, you should think about how it’ll be handled, BUT ALSO, your system explicitly should gracefully handle the case where it’s not uniformly present. It’s an explicit goal of protos to support the use case where heterogeneous schema versions are used over the wire.
If a bug is introduced because the caller and handler use different versions, the compiler wasn’t going to save you anyways. That bug would have shown up when you deploy or update the client and server anyways - unless you atomically update both at once. You generally cannot guarantee that a client won’t use an outdated version of the schema, and if things break because of that, you didn’t guard it correctly. That’s a business logic failure not a compilation failure.