Nil is IMO far and away Go's biggest wart, especially today with a lot of the early language's other warts filed off. And there's really no easy way to fix this one.

I think this article on channels suffers from "Seinfeld is Unfunny" syndrome, because the complaints about channels have largely been received and agreed upon by experienced Go developers. Channels are still useful but they were way more prominent in the early days of Go as a solution to lots of problems, and nowadays are instead understood as a sharp tool only useful for specific problems. There's plenty of other tools in the toolbox, so it was easy to move on.

Whereas, nil is still a pain in the ass. Have any nontrivial data that needs to turn into or come from JSON (or SQL, or XML, or ...)? Chances are good you'll need pointers to represent optionality. Chaining structVal.Foo.Bar.Qux is a panic-ridden nightmare, while checking each layer results in a massive amount of boilerplate code that you have to write again and again. Heck, you might even need to handle nil slices specially because the other side considers "null" and "[]" meaningfully distinct! At least nil slices are safe in most places, while nil maps are panic-prone.