3 ms·

The "billion dollar mistake" in Go is a non-issue: there's no security consequences (it panics safely) and it is the easiest kind of error to fix, it tells you

The "billion dollar mistake" in Go is a non-issue: there's no security consequences (it panics safely) and it is the easiest kind of error to fix, it tells you exactly where the null pointer is.

VBprogrammer 2y ago
Which is great if you are the exact person, team, and organisation which wrote the code and / or has access to the source code as well as the time and knowledge to know-how to fix it.
hansvm 2y ago
There's nothing I like more in the middle of the night than being paged about some skiddie making the webserver repeatedly panic ... safely. Surely you recognize the benefit in that sort of thing being pushed to a compiler error?
continuational 2y ago
Null pointer panics rarely happen where the null is introduced. Instead the null propagates somewhere else where you assume non-null, and you get the panic there. That's bad error reporting, and it only happens because Go lacks a proper nullable/option type.
kolektiv 2y ago
I'd agree with that if I hadn't had commercial products written in Go crash in production. They're the kind of errors that slip through the net, and "it's easy to fix" is shall comfort at 2am staring at a downstream 500 error.
kbolino 2y ago
The problem with nil in Go is that there's no ergonomic way to deal with it. Neither the language nor the type system are amenable to anything better. The lack of the ternary operator or any other conditional value expressions means that handling nil properly always adds at least three lines of code for every dot in an expression. Even generics don't help much because "nil" is actually 5 different things (nil pointer, nil slice, nil map, nil channel, nil interface) none of which are interchangeable. And strings can't be nil, which probably seemed like a cool idea at first but now just means you see *string all over APIs even though string is a fat pointer under the hood.

The "billion dollar mistake" in Go is a non-issue: there's no security consequences (it panics safely) and it is the easiest kind of error to fix, it tells you exactly where the null pointer is.

VBprogrammer 2y ago

Which is great if you are the exact person, team, and organisation which wrote the code and / or has access to the source code as well as the time and knowledge to know-how to fix it.

hansvm 2y ago

There's nothing I like more in the middle of the night than being paged about some skiddie making the webserver repeatedly panic ... safely. Surely you recognize the benefit in that sort of thing being pushed to a compiler error?

continuational 2y ago

Null pointer panics rarely happen where the null is introduced. Instead the null propagates somewhere else where you assume non-null, and you get the panic there. That's bad error reporting, and it only happens because Go lacks a proper nullable/option type.

kolektiv 2y ago

I'd agree with that if I hadn't had commercial products written in Go crash in production. They're the kind of errors that slip through the net, and "it's easy to fix" is shall comfort at 2am staring at a downstream 500 error.

kbolino 2y ago

The problem with nil in Go is that there's no ergonomic way to deal with it. Neither the language nor the type system are amenable to anything better. The lack of the ternary operator or any other conditional value expressions means that handling nil properly always adds at least three lines of code for every dot in an expression. Even generics don't help much because "nil" is actually 5 different things (nil pointer, nil slice, nil map, nil channel, nil interface) none of which are interchangeable. And strings can't be nil, which probably seemed like a cool idea at first but now just means you see *string all over APIs even though string is a fat pointer under the hood.