4 ms·

The opaque API brings some niceties that other languages have, specifically about initialization. The Java impl for protobuf will never generate a NullPointerE

by kyrra 2y ago

The opaque API brings some niceties that other languages have, specifically about initialization. The Java impl for protobuf will never generate a NullPointerException, as calling `get` on a field would just return the default instance of that field. The Go OpenAPI did not do this. For many primative types, it was fine. But for protobuf maps, you had to check if the map had been initialized yet in Go code before accessing it. Meaning, with the Opaque API, you can start just adding items to a proto map in Go code without thinking about initialization. (as the Opaque impl will init the map for you). This is honestly something I wish Go itself would do. Allowing for nil maps in Go is such a footgun.

the_gipsy 2y ago
> The Java impl for protobuf will never generate a NullPointerException, as calling `get` on a field would just return the default instance of that field. This is NOT the solution lmao
usrnm 2y ago
It's so fun to watch go devs rediscover all the patterns that they so happily threw out in the beginning. It's like watching a person grow up from a sunny little kid to a mature disgruntled alcoholic.
- rad_gruchalski 2y ago
  An alternative explanation is that non-go people got their hands on go and complain that go is not x or y. Like with generics. Now they’re in go. They’re not great, they have some sense but they may as well not exist as far as I’m concerned. I find them pretty useless anyway without lower and upper type bounds.
  - mxey 2y ago
    Which non-Go people brought generics into Go?
    - rad_gruchalski 2y ago
      „go can’t be taken seriously because it doesn’t have generics” has been a mantra for years before they finally arrived. there must have been a ton of them.
      - mxey 2y ago
        That does not mean that generics were somehow forced in against the wishes of the Go Team. Their position has always been that they just need to find a good design.
        int_19h 2y ago
        And everybody else laughed at the notion that there's a lack of good design for generics, given that all other mainstream languages have had them for literally decades, with many different takes to choose from. Given that Go eventually ended up with a very mundane take on generics, in retrospect, it is not at all clear what precluded this same design from being adopted from the get go rather than dragging their feet on it.
        mxey 2y ago
        Maybe you should read the various iterations of the design before you assume it dropped from the sky as-is.
        Cthulhu_ 2y ago
        > And everybody else laughed at the notion that there's a lack of good design for generics, given that all other mainstream languages have had them for literally decades, with many different takes to choose from. Yes, but they weren't good; half of the Java spec and implementations has to deal with its implementation of generics, and the author of Java's generics (Martin Odersky) then moved on to create the even more complicated Scala language. I have this comment [0] and its linked "Java generics FAQ" [1] that is exemplary of its complexity bookmarked for this very occasion. They ended up with a mundane take on generics because they dragged their feet on it. It's like that quote, "I would have written a shorter letter, but did not have the time." If generics were added without waiting for enough demand, use cases and consideration, it would have ended up weighing them (spec, language, compiler, runtime, etc) down for decades to come. Remember that Go is in it for the long haul. [0] https://news.ycombinator.com/item?id=9622417 https://news.ycombinator.com/item?id=9622417 [1] https://angelikalanger.com/GenericsFAQ/FAQSections/TypeParameters.html#FAQ106 https://angelikalanger.com/GenericsFAQ/FAQSections/TypeParam...
ynniv 2y ago
The Java impl for protobuf will never generate a NullPointerException, as calling `get` on a field would just return the default instance of that field. This was a mistake. You still want to check whether it was initialized most of the time, and when you do the wrong thing it's even more difficult to see the error.
- kyrra 2y ago
  Depends on your use. If you are parsing a message you just received, I agree that you want to do a "has" check before accessing a field. But when constructing a message, having to manually create all the options is really annoying. (I do love the java builder pattern for protos). But I do know the footgun of calling "get" on a Java Proto Builder without setting it, as that actually initializes the field to empty, and could call it to be emitted as such. Such are the tradeoffs. I'd prefer null-safety to accidental field setting (or thinking a field was set, when it really wasn't).
  - tantalor 2y ago
    > you want to do a "has" check before accessing a field You should only do that if the semantics of the not-set field are different than the default value, which should be rare and documented on the field.
    - ynniv 2y ago
      I too enjoy defining my default attribute values at the protocol level, so they can never, ever be changed, and then defensively coding library functions in case the arguments are not constructed under the same semantic assumptions as I had years ago. Also everything needs to be marked optional or you'll need to restart the whole service mesh to change the schema.
      - kyrra 2y ago
        Default values in proto are considered an anti pattern and was removed from the language in proto3. Agreed that protocol level required is bad, and it's with proto3 made optional the default. Our team enforces required fields via proto annotations, which can be much more flexible (we have transitional states to be able to upgrade or downgrade the check)

by kyrra 2y ago

the_gipsy 2y ago

> The Java impl for protobuf will never generate a NullPointerException, as calling `get` on a field would just return the default instance of that field. This is NOT the solution lmao

usrnm 2y ago

It's so fun to watch go devs rediscover all the patterns that they so happily threw out in the beginning. It's like watching a person grow up from a sunny little kid to a mature disgruntled alcoholic.

rad_gruchalski 2y ago
An alternative explanation is that non-go people got their hands on go and complain that go is not x or y. Like with generics. Now they’re in go. They’re not great, they have some sense but they may as well not exist as far as I’m concerned. I find them pretty useless anyway without lower and upper type bounds.
- mxey 2y ago
  Which non-Go people brought generics into Go?
  - rad_gruchalski 2y ago
    „go can’t be taken seriously because it doesn’t have generics” has been a mantra for years before they finally arrived. there must have been a ton of them.
    - mxey 2y ago
      That does not mean that generics were somehow forced in against the wishes of the Go Team. Their position has always been that they just need to find a good design.
      - int_19h 2y ago
        And everybody else laughed at the notion that there's a lack of good design for generics, given that all other mainstream languages have had them for literally decades, with many different takes to choose from. Given that Go eventually ended up with a very mundane take on generics, in retrospect, it is not at all clear what precluded this same design from being adopted from the get go rather than dragging their feet on it.
        mxey 2y ago
        Maybe you should read the various iterations of the design before you assume it dropped from the sky as-is.
        Cthulhu_ 2y ago
        > And everybody else laughed at the notion that there's a lack of good design for generics, given that all other mainstream languages have had them for literally decades, with many different takes to choose from. Yes, but they weren't good; half of the Java spec and implementations has to deal with its implementation of generics, and the author of Java's generics (Martin Odersky) then moved on to create the even more complicated Scala language. I have this comment [0] and its linked "Java generics FAQ" [1] that is exemplary of its complexity bookmarked for this very occasion. They ended up with a mundane take on generics because they dragged their feet on it. It's like that quote, "I would have written a shorter letter, but did not have the time." If generics were added without waiting for enough demand, use cases and consideration, it would have ended up weighing them (spec, language, compiler, runtime, etc) down for decades to come. Remember that Go is in it for the long haul. [0] https://news.ycombinator.com/item?id=9622417 https://news.ycombinator.com/item?id=9622417 [1] https://angelikalanger.com/GenericsFAQ/FAQSections/TypeParameters.html#FAQ106 https://angelikalanger.com/GenericsFAQ/FAQSections/TypeParam...

ynniv 2y ago

The Java impl for protobuf will never generate a NullPointerException, as calling `get` on a field would just return the default instance of that field. This was a mistake. You still want to check whether it was initialized most of the time, and when you do the wrong thing it's even more difficult to see the error.

kyrra 2y ago
Depends on your use. If you are parsing a message you just received, I agree that you want to do a "has" check before accessing a field. But when constructing a message, having to manually create all the options is really annoying. (I do love the java builder pattern for protos). But I do know the footgun of calling "get" on a Java Proto Builder without setting it, as that actually initializes the field to empty, and could call it to be emitted as such. Such are the tradeoffs. I'd prefer null-safety to accidental field setting (or thinking a field was set, when it really wasn't).
- tantalor 2y ago
  > you want to do a "has" check before accessing a field You should only do that if the semantics of the not-set field are different than the default value, which should be rare and documented on the field.
  - ynniv 2y ago
    I too enjoy defining my default attribute values at the protocol level, so they can never, ever be changed, and then defensively coding library functions in case the arguments are not constructed under the same semantic assumptions as I had years ago. Also everything needs to be marked optional or you'll need to restart the whole service mesh to change the schema.
    - kyrra 2y ago
      Default values in proto are considered an anti pattern and was removed from the language in proto3. Agreed that protocol level required is bad, and it's with proto3 made optional the default. Our team enforces required fields via proto annotations, which can be much more flexible (we have transitional states to be able to upgrade or downgrade the check)