I commend author for not shying away from writing such a take on one of the generally assumed consensus about code. However this just underlines again why glob

I commend author for not shying away from writing such a take on one of the generally assumed consensus about code. However this just underlines again why globals are usually good to avoid. It takes rigor not to make mistakes that can completely mess up with program state. I also strongly disagree with the benefits author advances for having global. Code feels actually less spaghetti when things are properly scoped and not accessible from everywhere, which hides extremely well dependencies and makes it way harder to reason about the code. One famous exception to that is indeed logging (which in itself is based on global state when printing to stdout or stderr anyway). And also > on account of how few places your object can be stored to you can store things in a single place, just once, without the need for globals.