There is something beautiful about global, mutable state:<p>Your program must be really small and scoped for this to make sense.<p>Also, kudos for providing so many corner cases to avoid that are non-trivial to formulate.<p>It feels like one of those "it's not impossible to do right" cases.<p>I'll just cite one evaluation point from the post:<p>> <i>It's extremely easy to use incorrectly.</i>
Hard disagree. Except for, begrudgingly, logging those are all bad uses and you shouldn't do them.<p>I find the append_work especially egregious. Never ever use a bloody global for that! Goodness gracious me. What an absolute and utter waste that provides zero utility. If you have a job system just pass a damn handle to the job queue. Good lord.<p>If everyone spent a little effort to not use globals the world would be a much better place. The value add of globals when they are mildly useful is so inconsequential such that it's basically never worth the effort.
I think the hatred of global variables comes from the fact that they are hard to use correctly. This article also makes the point that to use correctly you need to follow a bunch of rules.
I commend author for not shying away from writing such a take on one of the generally assumed consensus about code.<p>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.<p>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.<p>One famous exception to that is indeed logging (which in itself is based on global state when printing to stdout or stderr anyway).<p>And also<p>> on account of how few places your object can be stored to<p>you can store things in a single place, just once, without the need for globals.
> If you're using threads, global and static variables should be thread local. If they are not then the discussion becomes about sharing data across threads and synchronization, which is a different topic<p>Most languages make global and static variables thread-global by default, and making them thread-local is more work. I can see why, but that piece of language design causes a lot of global variable problems.<p>Also: you can simplify a lot of problems by deciding that something is going to be limited to n=1, whether that's variables or threads, and then a business reason comes along where you really want to have n=2. Suddenly every global is a source of regret.
IMHO mutable global state is totally fine if it is scoped to the current module or source file. Of course then it's not really 'global' anymore ;)<p>Immutable global state is fine to be accessible from the whole code base.<p>Pure functions are best of course, but you can't build real-world things entirely from pure functions.<p>The problematic approach lives somewhere inbetween, passing context/object references into deep callstacks isn't really a good solution for anything.
Well sure, if you're a great programmer you can do all kinds of things that are potentially dangerous, like using globals or lots of goto for control flow.<p>We stick to these kinds of rules because most people are not great programmers all the time. It's just mostly better to do the safe and boring thing most of the time.
You can make globals thread safe by using thread locals. You can make methods using them reentrant by carefully saving and restoring state. What about exceptions? Any exception from `process()` is going to leave this global state in a total mess.
> A Few Rules For Using Globals:
> If you change observable state, restore it<p>I’m sorry but no. Humans are human and mistakes will be made. I’ve lost count of the number of esoteric bugs I’ve had to track down due to global state being changed and not put back properly.<p>If you have to qualify a pattern with rules that are easily forgotten or open to corner case bugs, it’s far better to just not use that pattern in the first place.
"Cool. Now we need two work lists."<p>This is what you should do if you <i>must</i> use globals, but it doesn't really give any advantages.