GopherCon 2016: Francesc Campoy - Understanding nil

[@VitalyZdanevich]

Thank you for dark theme.

[@kamilziemian995]

Thank you Francesc Campoy. You teach me a lot.

[@grkuntzmd]

I've been programming in Go for a couple of years, but this clarified my understand of nil. Thanks.

[@kanaverum]

Wow, this was an incredibly informative talk. Thanks very much for this!!

[@christophertang7451]

different nils, "nil slice" is just a "nil slice" which is different to "nil pointer" which is different to "nil interface"...

[@stack.1]

2020 and still super informative

[@kamilziemian995]

I agree in 2023.

[@OOD2021]

Jesus christ, already 4 years ago people putting a gender disclaimer in their talks?

[@user-oh1pn6pt3l]

where can I find the slice thx

[@ioanvapi]

When I run this code: var ( aslice []string amap map[int]string afunc func() ) fmt.Println("aslice is:", aslice) fmt.Println("amap is:", amap) fmt.Println("afunc is:", afunc) it displays: aslice is: [] amap is: map[] afunc is: Therefore, why at 7:03 you say the zero value for slices and maps is nil? They looks to be empty slice and empty map !! I did expected to be displayed as for 'afunc' variable. By the way, when I added this code: if aslice == nil { fmt.Println("aslice is nil") } It has printed 'aslice is nil' :), therefore they are nil as in language specification but I suppose Println is confusing me. Maybe because we have different 'types' of nil in Go. I guess I have to watch the presentation again :).

[@JustForFunc]

every type can print their nil value in a different way, you can try it yourself play.golang.org/p/lxh_gqJ9as

[@ioanvapi]

OK, it depends how each type implements Stringer interface. Thanks.

[@andrewgerrand154]

It's not the types that implement Stringer (built-ins have no methods). Rather that's how the fmt package prints them.

[@themeeman]

It would be better if we could "opt out" of nil for specific types, especially maps, where we don't want it. Same for non nillable types so we could "opt in"

[@remariorichards8237]

how do one, register to talk at Gopher Academy

[@monquixote]

Is there any recording of the "Functional Go, Thanks, but No" available?

[@FrenchPirate83]

kzbin.info/www/bejne/pabceaNoo6-fZqs

[@scosminv]

kzbin.info/www/bejne/pabceaNoo6-fZqs

[@matthewbrowne3878]

I assume that when the speaker says "Occal" (at least that's what it sounded like) he meant to say the "Occam" language, right?

[@mharrisonb]

Oh. I didn't know there was a connection between Tony Hoare and OCaml, interesting.

[@mharrisonb]

Actually I just figured it out - he's saying "ALGOL". He specifically mentioned that he invented null in 1965, which matches this: en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions

[@quorkquork]

You implemented Maybe in a language that doesn't support typing rich abstractions, hence it was bad.

[@agendaaaa]

what is doError in kzbin.info/www/bejne/r5_SimWur5J5btU ?

[@Tevinsmind]

It implements the error interface.

[@john_rambo_27098]

That is just a dummy implementation for error{} interface merely to explain the interface {*something, nil} != nil concept.

[@agmmtoo]

// to watch

[@indianakernick3788]

17:35 "You're not using the pointer. You're not dereferencing it. It will just work. [...] This is different to C++". Actually, C++ allows this. If you don't dereference the nullptr, nothing bad will happen. You can call a member function on the nullptr and it will just work.

[@zerbitx]

I'm don't use C++, so if this is the scenario you're talking about that C++ allows, apologies, but what he's saying there is sayHi() is a method on type person. If you have a pointer to a person, we'll call frank, and that pointer is nil you can still call sayHi() and it will work play.golang.org/p/RtmcKuuzlUS

[@indianakernick3788]

Ryan Swanson That's what I'm saying. It works in Go and it works in C++. cpp.sh/9kyq5

[@anilkumar8753]

Your assumption is completely wrong, may work in debug build subjected you are not accessing any member variables of that class. In general, it will always lead to a crash.

[@indianakernick3788]

@@anilkumar8753 How could it always lead to a crash? It will crash if you're accessing a member variable. It will crash if you're calling a virtual function. If you're doing neither of those things then I don't see how it could crash. It is technically undefined behaviour in any case but practically speaking, I don't see how it could be unsafe. I tried this example godbolt.org/z/fv9cqM on various compilers and optimization levels and wasn't able to make it crash.

[@quananhmai5701]

Actually calling method is considered pointer dereference in C++, so the behaviour is undefined. If the behaviour is undefined, it may crash the program, it may not, but the language still forbids it and the program is ill-formed.

[@Andyzzzz501]

You only realize how stupid GoLang nil is when you work with a null-safe language like dart. What a dumpster fire GoLang is with all the creative ways your app can crash unexpectedly or hang in tight loops unexpectedly. If only one could have language with such a fast compiler as go, and such great runtime performance,but with checked nil safety, then it could have been really amazing. Instead these geniuses decided to design the language to be full to the brim with foot-guns while bragging how simple and easy to learn the language is.

[@jeffreysmith9837]

Then you realize how stupid is Dart's inability to cross compile to a single binary.

[@abdullahmujahid385]

@@jeffreysmith9837 wait wtf, how can you cross compile to a single binary?? don't think even go can do that!!