from Hacker News

I Like and Use Global Variables

by levodelellis on 2/7/25, 8:28 PM with 65 comments

• by sshine on 2/10/25, 8:23 AM

  There is something beautiful about global, mutable state:

  Your program must be really small and scoped for this to make sense.

  Also, kudos for providing so many corner cases to avoid that are non-trivial to formulate.

  It feels like one of those "it's not impossible to do right" cases.

  I'll just cite one evaluation point from the post:

  > It's extremely easy to use incorrectly.

• by forrestthewoods on 2/10/25, 9:07 AM

  Hard disagree. Except for, begrudgingly, logging those are all bad uses and you shouldn't do them.

  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.

  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.

• by metayrnc on 2/10/25, 8:46 AM

  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.

• by Ragnarork on 2/10/25, 10:41 AM

  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.

• by pjc50 on 2/10/25, 9:53 AM

  > 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

  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.

  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.

• by antithesis-nl on 2/10/25, 8:01 AM

  > For example, counter() keeps increments consistent

  No, not in the face of any sort of concurrency it doesn't...

• by flohofwoe on 2/10/25, 9:22 AM

  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 ;)

  Immutable global state is fine to be accessible from the whole code base.

  Pure functions are best of course, but you can't build real-world things entirely from pure functions.

  The problematic approach lives somewhere inbetween, passing context/object references into deep callstacks isn't really a good solution for anything.

• by progx on 2/10/25, 9:15 AM

  I Like and Use Global Variables, then I grew up. ;-)

• by MattPalmer1086 on 2/10/25, 12:11 PM

  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.

  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.

• by banthar on 2/10/25, 10:51 AM

  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.

• by matheweis on 2/10/25, 10:05 AM

  > A Few Rules For Using Globals: > If you change observable state, restore it

  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.

  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.

• by Vanit on 2/10/25, 8:27 AM

  You may as well just use a singleton pattern if you're going to do this, and at least that's easier to maintain if your use cases change.

• by zombot on 2/12/25, 7:16 AM

  There will always be people who have invincibly bad taste.

• by NooneAtAll3 on 2/10/25, 11:18 AM

  author, if you are here

  let's = let us, it is for suggestions

  lets = I let, he-she-it lets, it's the verb form

• by IshKebab on 2/10/25, 8:08 AM

  "Cool. Now we need two work lists."

  This is what you should do if you must use globals, but it doesn't really give any advantages.

• by BoingBoomTschak on 2/10/25, 8:12 AM

  The hatred of global variables for the sake of it is something that Common Lisp and its earmuffs un-brainwashed in me, thankfully.