3 ms·

Go would be amazing if it didn't allow dumb mistakes such as: type Human struct { Name string MaybeHasCat *Cat } type Cat struct {

Go would be amazing if it didn't allow dumb mistakes such as: type Human struct { Name string MaybeHasCat *Cat } type Cat struct { Name string } func main() { h := Human{} h.MaybeHasCat.Name = "Taffy" } And boom. Null pointer exception because MaybeHasCat is null. The fact that go doesn't let you define an optional type is such a pain. A lot of newcomers while getting trained up fall for this bug. edit: updating to add the pointer i missed. also adding a playground link: https://go.dev/play/p/izcod8xF7ZQ https://go.dev/play/p/izcod8xF7ZQ

koeng 2y ago
That’s not true. Here is a go playground of pretty much that exact code running just fine https://go.dev/play/p/v7OM9s_pRqY https://go.dev/play/p/v7OM9s_pRqY
- deathanatos 2y ago
  Steelman their example. Given that they named the member "MaybeHasCat", it's pretty clearly meant to analogue an Option<Cat>; if you correct the small typo then (make the type of "MaybeHasCat" a pointer, so that it can store nil for the other half of the Maybe), the example behaves exactly as they describe.
- iknowstuff 2y ago
  Wtf? what are you doing? Did the point fly over your head, are you being malicious by removing the star, or?
  - koeng 2y ago
    They added the star as an edit because of my playground link. So, neither
matrix87 2y ago
Could just do null -> none, nonnull -> some, optional doesn't introduce anything new here. Either you null check or you optional check Optionals are just another outlet for "best practice" bullshittery and not much else. If go doesn't have, sounds like they're following YAGNI principle
- ilrwbwrkhv 2y ago
  > Could just do null -> none, nonnull -> some, optional doesn't introduce anything new here. Either you null check or you optional check I am not sure what you mean by the first point but what I am saying is that the compiler doesn't stop you from having a basic runtime null pointer exception because of "simplicity" and "yagni".
archgoon 2y ago
I think you meant type Human struct { Name string MaybeHasCat *Cat } As you have written (not making MaybeHasCat a pointer), go will correctly initialize (at least as of go1.20.5) the nested Cat structure and allow for direct assignment. Having a null pointer exception for a null pointer is a behavior I would expect. Having one for a non-pointer structure would be surprising.
burnished 2y ago
That would work. It would need to be a pointer to get a nil pointer exception, or an interface (obv function call to trigger instead of field access), but there are some simple and common patterns you would follow to prevent that. Edit: should do more than just suggest the fix is easy So for pointer types you have two options IMO: nil checks, or getters that do the nil check for you. I think a map type instead of a string would also make your point more strongly because your zero value will fail on access. Which yeah that sucks to run into, and I'd agree actually that a lot of Go painpoints pop up early. I appreciate that now, because most of my foe stubbing was done inside the first few weeks, but it is undeniable imo.
- deleted 2y ago
  [deleted]
- ilrwbwrkhv 2y ago
  > nil checks, or getters that do the nil check for you Yes I agree there are patterns to solve for this but it is just strange that the compiler doesn't stop you from making these errors. I mean even Typescript has: interface Human { name: string cat?: Cat }
  - burnished 2y ago
    I don't know what 'even typescript' is supposed to mean. Are you saying that typescript is the natural bar for comparison here? That doesn't seem correct, isn't typescript a project that tries to correct javascript's lack of typing? Since it isn't an error to have a nillable type, and it isn't an error to access a field, it makes sense that the compiler doesn't error when you do that thing. If you want a warning when doing something silly then you can setup a linter. If your first thought is that is not very beginner friendly then I agree with you - I edited my original response. But otherwise there are solutions to these problems. If that doesn't suit you and Go isn't sweet enough for you, well, fair. Its rather austere. I don't think it is a categorical error for the project (though there are features I would also like for asking).
    - 2y ago

koeng 2y ago

That’s not true. Here is a go playground of pretty much that exact code running just fine https://go.dev/play/p/v7OM9s_pRqY https://go.dev/play/p/v7OM9s_pRqY

deathanatos 2y ago
Steelman their example. Given that they named the member "MaybeHasCat", it's pretty clearly meant to analogue an Option<Cat>; if you correct the small typo then (make the type of "MaybeHasCat" a pointer, so that it can store nil for the other half of the Maybe), the example behaves exactly as they describe.
iknowstuff 2y ago
Wtf? what are you doing? Did the point fly over your head, are you being malicious by removing the star, or?
- koeng 2y ago
  They added the star as an edit because of my playground link. So, neither

matrix87 2y ago

Could just do null -> none, nonnull -> some, optional doesn't introduce anything new here. Either you null check or you optional check Optionals are just another outlet for "best practice" bullshittery and not much else. If go doesn't have, sounds like they're following YAGNI principle

ilrwbwrkhv 2y ago
> Could just do null -> none, nonnull -> some, optional doesn't introduce anything new here. Either you null check or you optional check I am not sure what you mean by the first point but what I am saying is that the compiler doesn't stop you from having a basic runtime null pointer exception because of "simplicity" and "yagni".

archgoon 2y ago

I think you meant type Human struct { Name string MaybeHasCat *Cat } As you have written (not making MaybeHasCat a pointer), go will correctly initialize (at least as of go1.20.5) the nested Cat structure and allow for direct assignment. Having a null pointer exception for a null pointer is a behavior I would expect. Having one for a non-pointer structure would be surprising.

burnished 2y ago

That would work. It would need to be a pointer to get a nil pointer exception, or an interface (obv function call to trigger instead of field access), but there are some simple and common patterns you would follow to prevent that. Edit: should do more than just suggest the fix is easy So for pointer types you have two options IMO: nil checks, or getters that do the nil check for you. I think a map type instead of a string would also make your point more strongly because your zero value will fail on access. Which yeah that sucks to run into, and I'd agree actually that a lot of Go painpoints pop up early. I appreciate that now, because most of my foe stubbing was done inside the first few weeks, but it is undeniable imo.

deleted 2y ago
[deleted]
ilrwbwrkhv 2y ago
> nil checks, or getters that do the nil check for you Yes I agree there are patterns to solve for this but it is just strange that the compiler doesn't stop you from making these errors. I mean even Typescript has: interface Human { name: string cat?: Cat }
- burnished 2y ago
  I don't know what 'even typescript' is supposed to mean. Are you saying that typescript is the natural bar for comparison here? That doesn't seem correct, isn't typescript a project that tries to correct javascript's lack of typing? Since it isn't an error to have a nillable type, and it isn't an error to access a field, it makes sense that the compiler doesn't error when you do that thing. If you want a warning when doing something silly then you can setup a linter. If your first thought is that is not very beginner friendly then I agree with you - I edited my original response. But otherwise there are solutions to these problems. If that doesn't suit you and Go isn't sweet enough for you, well, fair. Its rather austere. I don't think it is a categorical error for the project (though there are features I would also like for asking).
  - 2y ago