Hacker News Reader

Comment by kyrra | Hacker News Reader

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.

View on HN

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.

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

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

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.

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)

> Depends on your use.

Okay, but look… If I wanted that, I’d create a wrapper library for it and call it a day. But not by default, please.

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.

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.

Which non-Go people brought generics into Go?

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

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.

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.

Maybe you should read the various iterations of the design before you assume it dropped from the sky as-is.

> 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

[1] https://angelikalanger.com/GenericsFAQ/FAQSections/TypeParam...

Java is one example out of many, and even in that case the limitations of their generics are largely caused by the desire for backwards compatibility, and it's a well-understood tradeoff.

Go ended up with a mundane take on generics because that is consistent with the design philosophy of the language as a whole. My point is that their mundane take on generics was already well-known and well-understood long before Go itself was even a thing, never mind all the rhetoric about "we don't have generics because we don't know how to do them well". If they ended up with some kind of novel arrangement that avoided complexity issues etc present in other generic type system, I would buy that argument. But when they ended up with the design that was there all along, it doesn't really add up.

> 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

Reply on news.ycombinator.com