Go has zeroed values, and you are encouraged to make them valid-but-empty. That includes zeroed pointers.
Is there a material difference between that and null? I don't care what I'm "encouraged" to do -- does the language force you to opt in to null?
Re:Reasons for using Golang
by JulianMorrison on Sunday June 12, 2011 @06:18PM
(#2647540)
http://golang.org/doc/go_spec.html#The_zero_value
Yes if you're using pointer-like things, but at least in Go it's an unsurprising thing, all uninitialized data is zeroed. And Go permits you to work with by-value structs and arrays if you want.
t.next == nil
Re:Reasons for using Golang
by JulianMorrison on Sunday June 12, 2011 @08:55PM
(#2647776)
On 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.
Tons 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.
Re:Reasons for using Golang
by JulianMorrison on Monday June 13, 2011 @07:15AM
(#2648679)
But 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.
In fact there are hardware models that fit Erlang better, such as non-cache-coherent NUMA. So from a certain perspective, it's not that C is low level, it's that the CPU was designed to execute C. And the CPU is anyhow general enough to be used in non-C-like ways.
I personally think Go missed a trick when it didn't require channel data to be provably impossible to alias across goroutines. (It could be immutable, pass-by-value, or "unique" such that aliasing is disallowed.)
As for nulls, Go actually doesn't really have them, the poster above is mistaken - Go has zeroed values, and you are encouraged to make them valid-but-empty. That includes zeroed pointers.