Earlier quoted context omitted.
"there's nothing stopping you from ignoring errors and continuing with what could easily be corrupt data." In theory, this is a big deal. In practice, it doesn't seem to be a problem. I've neither hit this very often myself, nor have I seen even newbies have much problem with it. A lot of error handling procedures are based on reacting to C, which was awful. You could call a function, and then have to call another fu…
> A lot of error handling procedures are based on reacting to C, which was awful Go's design decisions in general make a lot more sense from this perspective. "X was horrible to deal with in C, how can we make a (reactively) better version?" The problem is a lot of these choices (willfully?) ignore the decades of language innovation that have happened since C. They are incremental, reactive improvements, where it doe…
I get the sense that the designers have a huge amount of ego from making C what it is today.