GopherCon 2016: Understanding nil - Francesc Campoy
Why Stack Overflow recommends it
Stack Overflow users link it when answering questions about Go's nil semantics, especially the non-nil interface holding a nil pointer trap and returning error versus concrete error types.
Recommended by 6 people across 6 different months, 2016 to 2024.
What it is
A GopherCon 2016 talk by Francesc Campoy that walks through what nil means in Go for pointers, slices, maps, channels, functions and interfaces. It covers the different behaviours of each nil, why an interface holding a nil pointer is not itself nil, and why functions should return the error interface rather than a concrete error type.
What people said
Strong rec Hernan Garcia · 2019-03 · Stack Overflow · on “Calling a function on element of struct which is a nil pointer”
nil is the zero value for pointers // nil is a predeclared identifier representing the zero value for a // pointer, channel, func, interface, map, or slice type. var nil Type // Type must be a pointer, channel, func, interface, map, or slice type Source: [LINK] To understand nil this video is fantastic [this video]
Recommends zerkms · 2017-06 · Stack Overflow · on “Go pointer to interface is not null”
In Go interface types are represented by a structure with 2 fields: one denotes its actual type and the other is a pointer to the value. It means that an interface value is never equal to nil unless the value you passed is actually a nil value. Relevant and good talk: GopherCon 2016: Francesc Campoy - Understanding nil [this video]
Recommends Kanaverum · 2017-07 · Stack Overflow · on “Can an anonymous go function call itself?”
I agree with @milo-chirstiansen that it isn't possible for an anonymous func to refer to its instance in its declaration. If you're trying to get a feel for writing idiomatic Go code, it might look a bit more like this, doing away with the anonymous func: // Walk walks the tree t sending all values // from the tree to the channel ch. func Walk(t *tree.Tree, ch chan int) { Walker(t, ch) close(ch) } // Walker does the things, made to be called recursively func Walker(t *tree.Tree, ch chan int) { if t.Left != nil { Walker(t.Left, ch) } ch <- t.Value if t.Right != nil { Walker(t.Right, ch) } } You might find this interesting... Go allows some interesting things that aren't possible in other lang
Recommends Iain Duncan · 2018-04 · Stack Overflow · on “How to return custom errors without causing problems with nil values”
There is a really good gopher con talk about the different types of nil, including this common error where an interface pointer nil I'd not the same as an interface nil. [this video]
Recommends ls. · 2022-02 · Stack Overflow · on “Why is it recommended to return with the `error` interface in go rather than with the concrete error type?”
not sure why it gets downvoted but i think it's a valid question. this video might provide more explanation. [this video]
Recommends RubenLaguna · 2024-04 · Stack Overflow · on “Why is it recommended to return with the `error` interface in go rather than with the concrete error type?”
The reason is explained by Francesc Campoy in it's GophenCon 2016 - Understanding nil [this video] lecture. Particularly at the sections when is nil not nil [this video] and do not declare concrete error vars [this video] . The point he makes is that although you could use a concrete error type as the return type, and it will work as expected, it would break unexpectedly if later you or another developer convert that to an error interface. Then suddenly the err == nil check will give the "wrong result" since interfaces are only considered nil unless both it's type and value are nil . So you could start with a concrete error type like this (bad idea): func do() *doError { // concrete error type as return va
Recommends RubenLaguna · 2024-04 · Stack Overflow · on “Why is it recommended to return with the `error` interface in go rather than with the concrete error type?”
The link shared by Is [LINK] , starts too late, you need to start one minute earlier to get to the why "do not return concrete error types". You should start the video at 13:16 [this video] or 14:06 [this video]
Cites Randomblue · 2016-08 · Stack Overflow · on “What are the 5 secret keywords in Go?”
In this talk [this video] , Francesc Campoy has a slide with Go's 25 keywords, and apparently 5 'secret' keywords. What are the 5 secret keywords in Go?
Cites jub0bs · 2022-03 · Stack Overflow · on “Can I create channel without using the make function?”
TL;DR No way around it: you must use make . More details var c chan string merely declares a channel variable, but without initialising the channel! This is problematic because, as the language spec puts it [LINK] , The value of an uninitialized channel is nil . and A nil channel is never ready for communication. In other words, sending and/or receiving to a nil channel is blocking. Although nil channel values can be useful [this video] , you must initialise a channel at some stage if you ever want to perform channel communications (send or receive) on it. As mkopriva writes in his comment [LINK] , Go provides only one way of initialising a channel: A new, initialized channel value can be made us