this post was submitted on 18 May 2024
363 points (97.6% liked)
Programmer Humor
27378 readers
1975 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Kinda.
nilis a weird value in Go, not quite the same asnullorNonein JS and Python, respectively. Anilvalue may or may not be typed and it may or may not be comparable to similar or different types. There is logical consistency to where these scenarios can be hit but it is pretty convoluted and much safer, with fewer footguns to check fornilvalues before comparison.I'm other words, in Go
(nil == nil) || (nil != nil), depending on the underlaying types. One can always check if a variable has anilvalue but may not be able to compare variables if one or more have anilvalue. Therefore, it is best to first check fornilvalues to protect against errors that failure to execute comparisons might cause (anything from incorrect outcome to panic).ETA: Here's some examples
Thoroughly confusing lol. I think I need to check the spec in order to grasp this. I feel like this has more to do with the typing system rather than
nilitself, maybe. I'll see.But yeah, this is nothing like
nullorundefinedin JS, but more similar toNaN.Thank you for trying to explain!
Yeah... It's weird but I find it useful that it is, in a weird way. Treating it as an uncertainty means that one MUST explicitly check all pointers for
nilas part of normal practice. This avoids NPEs.