jsbrucker commented on PR #489:
URL: https://github.com/apache/incubator-pekko/pull/489#issuecomment-1638664988
It is possible what I have written below isn't relevant to this discussion
as I'm not entirely sure of the impact of this proposal. But I am concerned
that this is suggesting removing support for devs/users of Pekko from using
proto2 for communication between remote actors (or for integration with other
systems).
proto2 doesn't strictly need to be "maintained" (by an org like google) as
it is a stable spec, it's like maintaining tcp. proto3 is a competing standard
to proto2 not a replacement. proto2 still has significant usage, because among
other reasons getting rid of `required`/`optional` and not sending "default"
values over the wire don't align well with many use cases.
I'm sure the codebases I have worked on can't be the only ones, but the
distinction between `Some("")`, `Some(0)`, `Some(false)`, etc and `None`
can/should important semantic meaning, just as the distinction between
`required` and `optional` allows users or proto2 to ensure the code leveraging
the contracts aren't breaking any invariants (they just have to worry about
forward/backward compatibility themselves).
Protobuf isn't just used for archived data at rest and as APIs that require
100% forward/backward compatibility in perpetuity. For use cases where
developers have control over the deployment of all uses of a given proto
(implementation detail of a collection of services, or actors...) it often
makes much more sense to use proto2 and handle backward/forward compatibility
directly and be able to rely on the compiler erroring if the contract is
violated (particularly useful in a monorepo) instead of having to explicitly
write validators for every field.
In my experience it is usually an anti-pattern for a `case class` or API to
make every property/parameter an `Option` then write runtime validation to
ensure they are set or worse make them all non-Option types but set defaults
for all of them. Both situations result in code that is much more difficult to
maintain. To my mind protos effectively map to `case class`es or APIs so I
struggle to see why the patterns should be different.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
