> Go was the first language I used that broke an explicit check for nil/null/None. I had to cast my nil to a different kind of nil in order for the program to r

> Go was the first language I used that broke an explicit check for nil/null/None. I had to cast my nil to a different kind of nil in order for the program to run correctly. Maybe I'm reading it wrong, but it reads that you have been accustomed to implicit nil type conversions in other languages and that tripped you up when Go required you to be explicit. It seems Go is the explicit one here. > A library developer might decide to panic and cause your program to crash Go is abundantly clear that panics should never cross package boundaries except in exceptional circumstances. And those exceptions should crash your program. An exception means that the programmer made a mistake and the program is now invalid. There is nothing left to do but crash. It is technically true that a library developer can violate that guidance, but it is strongly encouraged for them to not. The parent did indicate that sometimes the explicitness is only encouraged, not enforced. Not that Go is some kind of explicitness panacea. It has its own fair share of implicitness. But I'm not sure these two are representative.