Typed nils in Go 2
dave.cheney.net
dave.cheney.net
The only thing that isn't so forgivable with Go is that these aren't new problems this time around. Go is still struggling to get over challenges that were first seen a long time ago. It's a great experiment on designing for complexity vs trying to avoiding complexity.
It's not surprising, it stems from the arrogance of Go designers who think they can eliminate complexity by deeming it irrelevant and making the user carry the weight of the complexity they refuse to deal with. Simplicity isn't hard, like Rob Pike says, it's a trade off.
If you're not going to have enums in your language for instance, you are forcing your users to implement their own, badly and in incompatible ways.
If you're not going to have generics, well you'll get this stupid situation where users are expected to "augment" the compiler with code generators, leading to an increase in complexity in building a program, or worse, ignoring compile time type checking since it's the path of the least resistance when dealing with generic container types.
And I'm all for the idea that relational fields should be NOT NULL. I also fear that this doesn't really work for backwards compatible thinking. If I serialized some data down to disk before a field existed, I don't expect it to be there when I check it later.
You can be tempted to think it should just be the zero value of the type you are using. Or you can add some extra boilerplate around accessing. I think either works. Just make sure you aren't getting carried away. And, try to do anything that cares about the absence or presence of something at a layer from where you get that something. Don't punt the decision down your codebase.
(That is, Optionals are great at the layer, don't pass them as parameters to inner code, though. Obviously, YMMV. And, quite frankly, probably will go further than mine.)
What if the data is actually missing? How else do you record that information?
Having an extra field for "missingness" is less safe because the type system won't enforce that it is either missing or set, you could have it set to a value but marked as missing which is still ambiguous.
I concede there may be no difference in those meanings.
I avoid the word "empty" when referring to anything SQL related, as it is ambiguous in three value logic.
SELECT a.id, b.name FROM a LEFT JOIN b ON a.id = b.id
If you get a NULL in the name field, you don't know if that's because there's no record in b for that id, or if there is a record in b for that id but it has a NULL name value. Sometimes that difference will be important.
Conceptually NULL or nil is an appropriate concept for results that have no meaning, such as if an error occurred or if a passed value is not required or valid. (Though some structures can contain data that is 'incomplete' or 'not checked' and thus while a valid structure might not be 'validated' in the sense of conforming to a more specific set of expectations.)
field_is_set = true, field = "123"
field_is_set = false, field = 0 (some zero value or uninitialized value)
But isn't that a really clunky way of checking whether field is set? You can't just check field because the "zero value" could be a legit value, e.g. zero. So you have to first check field_is_set -- and now you have to make sure that's always correct and that nobody ever sets field by itself.
The question I ask in these circumstances: Will a method/function //always// return valid work if the program continues to run?
How about a 'find' function of some type? Find the nth thing, find matches of X, etc.
That's one type of function that might return no answer.
If a list or set of some sort is expected I'm happy with a zero-length list in this case. However lists aren't the only time this happens. The most recent example to come to my mind is finding the Nth item in an arbitrary sequence. That item might be out of bounds (not exist). Nil is appropriate for that case.
What happened to "lightweight typesystem that reduces cognitive load"?
The intention was great and the result wasn't that great, but it still works pretty dann well. Go is an open language and they are asking for well thought out proposals on where & why the problems exist. Followed by ideas and/or examples to make it better so let's all try.
I think Maybe Types would be an amazing feature to add. Closed types would also be an outstanding win from a UX perspective. Neither of those concepts would add more cognitive load then they remove in my opinion.
From what I've seen, this holds only as long as you keep the proposals minimal and restricted to aforesaid hacking around the limitations built into the language. I'm happy to be shown evidence to the contrary: have there ever been any proposals, reacted to in a not-completely-negative way, that were like "uh, maybe we didn't have the right idea about <something basic>, let's do this instead"?
I'll argue there won't be. Every community has a culture: Go's is delightfully warm, friendly, and inclusive, but also surprisingly distrustful of learning that there are easy-to-understand but powerful language features they could be using to write maintainable code without "getting a PhD in type theory from the nearest university" (to strawman a certain [type of] person [I've often encountered when arguing about these things]).
Go has done many things right (aside from the community, good concurrency and really fast compiles come to mind) but language design is not one of them.
Even so, I'm all for praising the good things that Go does: if nothing, because of the tremendous mindshare it's getting and the number of people it reaches.
For example, Turbo Pascal 5.5 targeting MS-DOS was released in 1989 and was compiling 34,000 lines/minute.
https://edn.embarcadero.com/article/20803
This is just one example, there are plenty of other languages to choose from with a module based compilation model, only C and C++ toolchains have lousy build times given their textual inclusion model.
http://www.drdobbs.com/cpp/c-compilation-speed/228701711
So the only achievement of Go's compilation speed was making younger generations think it is something extraordinary.
Is it, really? I haven't seen a more hostile open source project to outside ideas / requests regarding to language itself.
It's just open source.
Oberon is an example of a true lean programming language. The complete language reference takes up only sixteen A4 pages. The compiler OBNC implements the latest version of the language:
func DoStuf(i ILoveGoer) {
i.LoveGo() // Panic on nil
}
Once you have an either type, you can also get rid of nil entirely since a Maybe type is trivially created with an Either.
Designing languages without a null value (other than for c-interop via e.g. `C.null`) is a solved problem.
I expect the implementation and grammar/syntax addition would be the most difficult as that seems to be what one of the main focuses was during Go's infancy, make the language as easy as possible to parse/lex.
I'm sorry to bring the age-old "but generics" thing up, but how do you even implement (what Haskell-alikes call) Functor without parametric polymorphism?
The only ways I see are
a) Elm-style List.map/Array.map/Maybe.map
b) Rust-style Functor/Monad operations on specific types like Result
Which of these do you think Go would be more receptive to?
The only other option is to not have nil values.
Null is not a value of bottom type. Bottom type has no values.
Rust has a bottom type (!)[0] without it implementing all traits by default while using a different type (Result) for error propagation. Plus having nil/null as a a value of the bottom type violates some aspects of bottomness.
[0] https://github.com/rust-lang/rfcs/blob/master/text/1216-bang...
type JoeLovesGo struct{}
func (jlg *JoeLovesGo) LoveGo() {
fmt.Printf("Joe Loves Go! jlg is %v\n", jlg)
}
Now, if this (admittedly uncommon) use-case is worth it's downsides is a different question, but that's how it's set up now.
https://crystal-lang.org/api/Nil.html https://crystal-lang.org/docs/syntax_and_semantics/union_typ...
Python added type hints recently, but in Common Lisp, there is not only a null type (which contains the nil value), but also an empty type: there is no practical use in defining a type for which there is no possible value at runtime, except if the language and its type system are designed to support static analysis. It it expected that a compiler can optimize away things that are known in advance to be impossible, or help you detect errors statically.
The nil type is useful at run-time because it constitutes the bottom of the type spindle: just like in set theory the empty set is a subset of every set, including itself, the type nil is a subtype of every type, including itself.
This can be used at run-time; e.g. (subtypep nil 'integer) -> t.
We can't just exclude this value from the type domain on the grounds that it's static only. "Sorry, you don't get a bottom plug on your type spindle at run time ...". :)
var b *bytes.Buffer
var r io.Reader = b
fmt.Println(r == nil)
I have thought a bit about it but I couldn't come up with good situations.
For example:
func returnsNil() error { return nil }
x := returnsNil()
// x is of type nil and value nil. var a interface{} = nil // (nil, nil)
var b *int = nil
var c interface{} = b // (*int, nil)
fmt.Println(a == c)
And that's vicious because something as seemingly innocuous as "extract variable" on an immutable literal can break your code.
var a interface{} = nil // (nil, nil)
fmt.Println(reflect.TypeOf(a) == nil)Ignoring the compatibility guarantee for the sake of discussion, I feel that nobody would notice if the compiler tomorrow started short-circuiting the equality check of interfaces against nil to return true if either tuple value is nil. But maybe I'm missing some use-case.
I think that's two different questions:
* Is there a legitimate use case for nil not being nil? I don't think so.
* Is there a legitimate use case for having "typed nil" interfaces? Kinda, Go supports and encourages calling methods "with nil receivers", and doing that through an interface requires that the concrete type (the non-nil half) be conserved otherwise you can't dispatch the method call.
As I wrote below:
Ignoring the compatibility guarantee for the sake of discussion, I feel that nobody would notice if the compiler tomorrow started short-circuiting the equality check of interfaces against nil to return true if either tuple value is nil. But maybe I'm missing some use-case.
while nil is assigned to t2, when t2 is passed to factory it is “boxed” into an variable of type P; an interface. Thus, thing.P does not equal nil because while the value of P was nil, its concrete type was *T.
> But regardless of the bad design of Go around the usage of "nil", the code would have failed in pretty much any other language anyway.
No, it would not. In Java, null is null whether it's typed as a concrete reference, as an array or as an interface.
Sorry, it's a method not a property, but I think my point remains valid with regards to the example in that article. Just to be clear, I'm not trying to defend nil here, but I do think it's important to understand the issue because I think the authors code would have failed regardless of the language. So Let's break the code down: first they create a struct exposed via an interface{}
type T struct{}
func (t T) F() {}
type P interface {
F()
}
Then they create an initialized variable that object type:
t := newT()
t2 := t
if !ENABLE_FEATURE {
t2 = nil
}
thing := factory(t2)
fmt.Println(thing.P == nil) // returns nil
That all said, I do feel your examples are a lot more relevant to this discussion than the one that prompted the discussion to begin with.
Most OO languages wont report an interface as non null if its value is null. Go will.
Not really, Go supports (and encourages properly handling) nil method receivers.
> Most OOP languages would raise an exception / print runtime error (in the case of JIT dynamic languages) or downright crash if you tried to access methods or properties of a nil / null / whatever type.
Setting aside the fact that this is not quite true[0], there is a gulf between "failing" as a clear runtime (or compile-time) error at the point of an incorrect invocation, and "failing" by silently yielding a nonsensical state and possibly but not necessarily faulting at some other point later on. PHP gets regularly and deservedly panned for the latter.
[0] nil is a message-sink in obj-c (any message can be sent to nil and will be a no-op returning nil), and you can make Ruby or Smalltalk behave that way (or any other) as their nil is a regular object with a normal type which you can go and extend
Of course. But then I also made that point too. Frequently in fact and in the very post you're replying to as well. Plus also in the other reply that echoed the same point you're raising here. I'm not justifying Go's behavior here. Absolutely not! It is unexpected and bad. But we have already established and agreed on that point so moved onto another question regarding whether the authors example is an issue that is likely to arise often. I was attempting to explain why I felt it was a poor example and not trying to justify Go's behavior - which at risk of repeating myself: we all already agree is bad.
Only you're not doing that here. If anything, it's the inverse.
>But regardless of the bad design of Go around the usage of "nil", the code would have failed in pretty much any other language anyway.
In other languages the interface can be null as a value even if the interface has a not-null type.
Honestly if you aren't a skilled enough programmer to navigate the nuances of any particular language then you really are no better than kids playing in drag-and-drop environments like Scratch.
result, err := Foo()
if err != nil {
...
}
The next decade will see Go adding in most or all the complexity real-world software asks for, without ever admitting that maybe it should've been supported from the beginning without the hacky workarounds.
> Honestly if you aren't a skilled enough programmer to navigate the nuances of any particular language then you really are no better than kids[...]
Even though the bit in italics is pretty much the opposite of the "Go/JS pitch", I'll bite.
Sure, learning to code at a high level means you need to take time to learn things (which is the opposite of the pitch). I just don't get why teaching yourself to "navigate the [brokenness]" of a language that was out-of-date the day it was released is preferable to learning to write in an expressive language that won't artificially handicap you or provide you with an arsenal of footguns.
In all the time you were casting to and from interface{}, you could be exploring and using powerful and practical new ideas that make it less likely you'll suffer for failing to check one of those "err"s.
Honestly, I don't mind error handling in Go. I've used a wide variety of languages in production systems (I've lost count but it's more than a dozen) and I've found Go to be surprisingly good at giving detailed, context aware breakdowns of where issues arise and allowing me to easily handle them. Sure there are a thousand different ways to do this and Go picked the ugliest, but in spite of that I've found it to be surprisingly effective - even in the more complex projects I've written like murex (my alternative UNIX $SHELL) and the odd Linux FUSE file system I've written to scratch a particular itch.
In fact for as many complaints like yours I've read there are also as many seasoned developers complementing Go's error handling. So I really think that particular issue is more a matter of personal taste rather than poor language design.
However I'm _not_ going to defend the nil thing nor how interface{}'s are (ab)used as an alternative to generics. Those _are_ just bad design choices.
But for all of Go's sins, I still find myself more productive writing Go code than I have in any other language for a long time (probably since writing Pascal in Borland's Turbo Pascal back in the 90s). Hence why I defend Go. I can understand idealistic opinions about language design (Go is opinionated too after all) but frankly what really matters is a developers ability to get an idea into something executable. And I feel a lot of the complaints about Go really miss the point about how productive that language is to a great many people and without sacrificing too much control to be useful in a practical sense.
People who complain about it don't grok the Go ethos. That's fine, it's not for everyone.
How about you study the language a bit more in depth (including estabilished idioms) before pontificating about it?
I'll note that The Fine Article is about why one of those established idioms confuses newcomers. Even better, it bites people because the type of an interface needs to be nil for something to work. (Insert appropriate expression of astonishment here.)
Enforcing patterns hiding inadequacies in the implementation works less well than one would imagine, e.g. look at all the languages that Go sought to improve upon and the baggage of "design patterns", GoF-alikes, etc. that they brought with them.
> return early
I was just going off what I found at https://blog.golang.org/error-handling-and-go.
I assume you meant this (in Go-ish pseudocode)?
result, err := Foo1()
if not err {
Panic(err)
}
result2, err2: = Foo2(result1)
if not err2 {
Panic(err2)
}
result1 <- foo1
result2 <- foo2 result1
2. I think the arrow means assignment in Haskell and you are just referring to monadic errors? To use them the same way proper error handling is done in Go, you would just have more nesting and multiple unwraps, which is marginally different than Go syntax (but definitely with more compiler checking.) The arrow syntax in Go is used by channels.
a, err := squareRoot(x)
if err { handle(err) }
b, err := log(a)
if err { handle(err) }
c, err := log(b)
if err { handle(err) }
a :: Double -> Maybe Double
a <- squareRoot x
b <- log a
c <- log b
That's trivially feasible and still shorter than the Go version:
a <- decorate (squareRoot x)
b <- decorate (log a)
c <- decorate (log b)
At the end of the day it doesn't make any more sense to apply Haskell methodologies to Go than it does to complain that Haskell is missing some fundamental features of Go. They're distinctly different languages. But despite this I've noticed you spend a lot of time in various Go discussions on HN moaning that Go isn't more like Haskell.
https://rustbyexample.com/std/result.html
Ergonomic error handling or generics/parametric polymorphism aren't "Haskell methodologies". Go is one of a very small number of languages that have been designed in the last decade and lack features like this.
The reason I participate in HN comment threads about Go is largely how entertaining I find comments strenuously rationalizing Go's inadequacies. In one (very recent but definitely memorable) case[1], I was told that
> You [should] first reconsider your need to make a generic data structure and evaluate on a case by case basis.
(I'm not sure why you made that edit, but I've made a mental note of what the last bit said. Arguing on the internet is a difficult, if useless, skill, and I'd hate to be tiresome.)
func readNumberFromFileAndDoubleIt(filename string) (int, err) {
file, err = os.Open(filename)
if err != nil {
return 0, err
}
defer file.Close() // BUG!! this returns an error, but since we defer it, it is not going to be handled
bytes, err := ioutil.ReadFile(filename)
if err != nil {
return 0, err
}
contents := string(bytes)
i, err := strconv.Atoi(contents)
if err != nil {
return 0, err
}
return 2*i, nil
}
fn read_number_from_file_and_double_it(filename: &str) -> Result<i32> {
let mut file = File::open(filename)?; // file automatically closed at end of scope
let mut contents = String::new();
file.read_to_string(&mut contents)?;
contents.parse().map(|i| 2*i)
}
Any practical code using Results soon ends up wanting to mix the errors from multiple sources. This requires a lot of boilerplate effort to make everything interop, and the machinery to reduce this is both complex and not standardised. If you don't go the upfront boilerplate-and-machinery route, things look awful.
And of course, if you use something else, like an Option, you're back to
let foo = match bar() {
Some(foo) => foo,
None => return None,
};
Your example is especially disingenuous, though. For example, you chastise Go with
defer file.Close() // BUG!! this returns an error, but since we defer it, it is not going to be handled
Rust's error handling looks nice on fake examples, and manageable inside self-contained libraries. My experience of actually using multiple libraries is that Rusts error handling is a choice between tangly handling of nested errors or verbose attempts to early-exit.
[1]: https://github.com/rust-lang/rust/blob/master/src/libstd/sys...
As to specifically whether I have used error-chain, not really. I no doubt will in the future, but I'm not seeing Rust on my plate for a while.
Public cosplay of [presumed] intelligence as a new smoking.