3 ms·
t.next == nil I don't give a fuck whether it's called null or 0 or nil or whatever, or whether it's amazing or surprising or shocking. Every single pointer has
by sid0 15y ago
t.next == nil
I don't give a fuck whether it's called null or 0 or nil or whatever, or whether it's amazing or surprising or shocking. Every single pointer has null as a possible value, which means Go suffers from what I think is the biggest possible mistake a (non-scripting) programming language could make (and I'm not alone -- Tony Hoare thinks the same). The worst thing about all this is that we already have a well-known and well-studied solution in the Maybe monad, yet the Go designers buried their collective heads in the sand here.
- JulianMorrison 15y agoOn the upside, Go does not suffer from the common Java anti pattern of returning a semantically meaningful null. Its multiple return means that while it can't return "Maybe Foo", it usually returns something like "Either Error Foo", with the multiple assignment taking the place of a rather primitive pattern match. Also a go function is typically structured like a primitive Either monad - it returns with an error immediately if it gets one, or else it returns from the end with a value.
- sid0 15y agoTons of functions in most imperative languages are structured in an early-return-on-error style, with exceptions simply being a special case of that. That is neither novel nor uncommon.
- JulianMorrison 15y agoBut not with multiple return where (as an idiomatic design pattern) the same error object is passed up through the call stack until something decides to handle it, which is what the Either monad does. (And unlike exceptions, the Go way and the Either monad are both explicit, there are no unmarked returns.) The C way with single return means that it's generally impossible to just forward the same error object - the caller has a different type from the callee, so where one returns null another has to return -1, and so forth.