3 ms·

I've heard this several times - "Go would be great if only they added <my-favourite-feature>"... Go's philosophy is that a coherent, curated feature set is as

by pansa2 2y ago

I've heard this several times - "Go would be great if only they added <my-favourite-feature>"... Go's philosophy is that a coherent, curated feature set is as valid an approach to language design as the C++/Python/... approach of adding every possible language feature. In particular I doubt Go will ever add null-safety - given the above philosophy, the language's pervasive use of "zero values", and its strong commitment to backwards compatibility.

EdwardDiego 2y ago
How do you distinguish between a value set to zero value explicitly, and one not set?
- jochem9 2y ago
  There is no difference. You need to handle that based on the context you're in.
  - EdwardDiego 2y ago
    I was wondering if there's a pattern of using Option types or something to signal the difference. I ask because I hit this issue a fair few years ago with protobuf v3, we ended up using a wrapper type pattern. Can't recall why it was important to know at the time, but it was.
    - the_gipsy 2y ago
      Sometimes you can abuse pointers as a (very) poor man's Option<T> type. But it's turtles all the way down, you can't distinguish between for example `null` and "missing" when parsing JSON.
  - mervz 2y ago
    Yikes...
- kzs0 2y ago
  In the cases where this is important, you can use pointers. Go allows you to make pointers to primitives as well (making the zero value nil) so you can explicitly define those edge cases. You’d be surprised how infrequently that’s actually a concern though.
  - deergomoo 2y ago
    Using pointers feels horrible as a workaround though because it completely muddies the intent. Is it a pointer because it could be zero or <not set>, is it a pointer for performance reasons, is it a pointer because the function mutates it? To me it flies directly in the face of Go's desire to keep things simple and easy to reason about. > You’d be surprised how infrequently that’s actually a concern though I admittedly don't write a huge amount of Go, but I run into this fairly often any time I'm dealing with user input. Something like an optional numeric input is not at all uncommon.
  - metaltyphoon 2y ago
    How do you have a PUT on an API to “unset a field”?
  - Neikius 2y ago
    What? That is actually an everyday concern and devs assuming that information is not needed will bring pain down the road. Just two cases of the top of my head: working with databases and json interop with other systems that actually do differentiate. And the second one should not happen, but people do make assumptions and sometimes those are inherently incompatible with how golang works.
pkolaczk 2y ago
I can’t see how Go feature list is any more curated or more coherent than in other languages. Seriously to me it feels like many Go features were rushed and some added despite the evidence they are a bad idea. Like, why an unused import / unused variable is a hard error but an unused function is not? Or why for a very long time maps and channels were special by being generic but you could not use generics in your own types (that has fortunately changed). Why add nil / default values at the time where virtually everybody knows this is a bad feature and there are better solutions established?

by pansa2 2y ago

EdwardDiego 2y ago

How do you distinguish between a value set to zero value explicitly, and one not set?

jochem9 2y ago
There is no difference. You need to handle that based on the context you're in.
- EdwardDiego 2y ago
  I was wondering if there's a pattern of using Option types or something to signal the difference. I ask because I hit this issue a fair few years ago with protobuf v3, we ended up using a wrapper type pattern. Can't recall why it was important to know at the time, but it was.
  - the_gipsy 2y ago
    Sometimes you can abuse pointers as a (very) poor man's Option<T> type. But it's turtles all the way down, you can't distinguish between for example `null` and "missing" when parsing JSON.
- mervz 2y ago
  Yikes...
kzs0 2y ago
In the cases where this is important, you can use pointers. Go allows you to make pointers to primitives as well (making the zero value nil) so you can explicitly define those edge cases. You’d be surprised how infrequently that’s actually a concern though.
- deergomoo 2y ago
  Using pointers feels horrible as a workaround though because it completely muddies the intent. Is it a pointer because it could be zero or <not set>, is it a pointer for performance reasons, is it a pointer because the function mutates it? To me it flies directly in the face of Go's desire to keep things simple and easy to reason about. > You’d be surprised how infrequently that’s actually a concern though I admittedly don't write a huge amount of Go, but I run into this fairly often any time I'm dealing with user input. Something like an optional numeric input is not at all uncommon.
- metaltyphoon 2y ago
  How do you have a PUT on an API to “unset a field”?
- Neikius 2y ago
  What? That is actually an everyday concern and devs assuming that information is not needed will bring pain down the road. Just two cases of the top of my head: working with databases and json interop with other systems that actually do differentiate. And the second one should not happen, but people do make assumptions and sometimes those are inherently incompatible with how golang works.

pkolaczk 2y ago

I can’t see how Go feature list is any more curated or more coherent than in other languages. Seriously to me it feels like many Go features were rushed and some added despite the evidence they are a bad idea. Like, why an unused import / unused variable is a hard error but an unused function is not? Or why for a very long time maps and channels were special by being generic but you could not use generics in your own types (that has fortunately changed). Why add nil / default values at the time where virtually everybody knows this is a bad feature and there are better solutions established?