4 ms·
My answer to this recurring question: http://www.jerf.org/iri/post/2957 http://www.jerf.org/iri/post/2957 The really short answer is that the problem stems fro
by jerf 4y ago
My answer to this recurring question: http://www.jerf.org/iri/post/2957 http://www.jerf.org/iri/post/2957
The really short answer is that the problem stems from a incorrectly imported concept from C, where void pointers are all 0. If you treat Go as Go, and don't try to understand it as another language, you would understand there's no particular reason to treat nil the way people are treating it. It isn't a void pointer. There's also an issue where people incorrectly attribute the problem; it isn't where the nil (of one type) fails to compare equal to nil (of another type), it's where the value was created in the first place that didn't mean what a C-based understanding thought it meant. Go isn't C, just like any language X isn't language Y.
In reality, once you understand this issue correctly, it essentially dissolves simply because you have the correct understanding. I've been programming in Go now for years and I simply don't hit this problem. You do have to be willing to let go of your wrong ideas, but, it's not a matter of opinion about design or something; they are objectively wrong ideas about how the values in Go work. Once you move the problem from trying to "detect" the problem to not creating the problem in the first place, it's not hard.
- avgcorrection 4y ago> In reality, once you understand this issue correctly, it essentially dissolves simply because you have the correct understanding. When you understand something then you don’t have a problem understanding it any more.
- philosopher1234 4y agoHe's saying theres a simple mental model where this all makes sense. That's not always the case, despite your implication.
- nicoburns 4y agoThe real problem is that they imported the concept of null/nil being a value of every type from C. Null/nil is fine (although Option/Optional/Maybe is better when you want to nest), but it should be an opt-in part of the type such that it is a compile time error to assign a null/nil value to a variable unless it's the nullable variant of the type.
- ok_dad 4y agoActually, not all Go types are nilable. Integers and strings; those things aren’t nilable. Pointers, interfaces, slices, and some other stuff is. I’m new to Go so I don’t remember the rules exactly, but you can look up the exact details I’m sure.
- masklinn 4y ago> Integers and strings; those things aren’t nilable. Which is then annoying because if you want an optional integer you now need a pointer, and a heap allocation.
- convolvatron 4y agodoes anyone else think Go would be a much better language without the pointer distinction? maybe an explicit mutable type modifier instead?
- ok_dad 4y agoYea, I think references to other values should be a type, like a `Reference[T]`. Then you can pass something by reference, rather than value, without having confusing referencing/dereferencing. A `Reference[T]` could have some sort of element reflection, where you can just use it like it's a `T`. Pointers, referencing, dereferencing; that can get confusing even for skilled engineers.
- ok_dad 4y agoThat's one of the most annoying things to me coming from Python: the inability to have a default argument value.
- ecnahc515 4y agoGo can use escape analysis to determine if a heap allocation is actually required in some cases.
- the_gipsy 4y ago
- the_gipsy 4y agoSo can you define what it is, beyond "not like a C void pointer"? Because effectively, basic pointer behavior (nil check) is dangerously (panics) different depending on returning a nil interface or nil *struct (both are interchangeable). Granted, I don't run into this problem every day, but it's not due to "understanding the issue correctly".
- xdavidliu 4y ago> C, where void pointers are all 0 I think you mean "null pointers are all 0". void pointers are something entirely different, and certainly not always 0.