12 ms·

Global variables are not the problem

• cies 2y ago
  > Global Variables Are Not the Problem It should have been "Mutability is the Problem, Globalness is not".
  • levodelellis 2y ago
    I'm the author. No, I completely disagree. No one ever complains about logs and malloc except having too much of them - A line I removed from this article The next article has examples and IMO much better, but makes no mention of action at a distance, and currently makes no mention of how people use clone to prevent mutability.
    • cies 2y ago
      I dont understand how your comment relates to my comment, beyond that you disagree.
      • levodelellis 2y ago
        I like mutation in global variables. I don't think it's the problem. I'm explaining it in my next article
• serbuvlad 2y ago
  I find the concept of a context structure passed as the first parameter to all your functions with all your "globals" to be very compelling for this sort of stuff.
  • leetrout 2y ago
    The "god object"
    • thaumasiotes 2y ago
      The "environment".
      • KPGv2 2y ago
        couple dudes pooh-poohing the reader monad
  • caspper69 2y ago
    Hard disagree. If I have 500 functions, I don't want to extrapolate out the overhead of passing a state object around to all of them. That's a waste of effort, and frankly makes me think you want to code using an FP paradigm even in imperative languages. Module-level and thread-level "globals" are fine. You gain nothing (other than some smug ivory tower sense of superiority) by making your functions pure and passing around a global state object to every single method invocation.
    • pdimitar 2y ago
      Hard to take your comment seriously when you go out of your way to degrade a discussion opponent, FYI.
      • deleted 2y ago
        [deleted]
      • caspper69 2y ago
        My comment was not intended to be personally degrading to OP. Apologies if it was taken that way.
        • pdimitar 2y ago
          I did not say you are targeting OP. I meant that you are degrading your parent commenter. This: "You gain nothing (other than some smug ivory tower sense of superiority) by making your functions pure and passing around a global state object to every single method invocation." ...is neither productive nor actually true. But I'll save the latter part for your other reply.
          • caspper69 2y ago
            I'll take my medicine. :) I'm not above being put in my place and being shown the light. (And when I said OP, I did mean the parent poster) You should also understand that the "you" in my comment you quoted is the colloquial you and not necessarily the parent poster. So lay it on me.
  • deleted 2y ago
    [deleted]
  • bee_rider 2y ago
    That just seems like globals with extra steps. Suddenly if your context structure has a weird value in it, you’ll have to check every function to see who messed it up.
    • bigcat12345678 2y ago
      That's 2 parts: 1. Global variable (mutable) 2. Local function with context argument (mutations) You have clear tracking of when and how functions change the global variable
    • Joker_vD 2y ago
      First, that's true for globals as well. Second, with "context structure" pattern, the modifications to it are usually done by copying this structure, modifying some fields in the copy and passing the copy downwards, which severely limits the impact radius and simplifies tracking down which function messed it up: it's either something above you in the call stack or one of the very few (hopefully) functions that changes this context by-reference, with intent to apply such changes globally.
  • levodelellis 2y ago
    That's exactly why I used this specific example. I seen many code bases that use clone to avoid mutation problems so I wrote this specifically to show it can become a problem too. I wrote a better article on globals. I plan on posting it next week
    • dkersten 2y ago
      This seems more an issue with not understanding structuralClone, than one of understanding globals or lack thereof. There’s nothing wrong with the example, it does exactly what the code says it should — if you want counter to be “global” then structuralClone isn’t the function you want to call. The bug isn’t in how counter was in obj, the bug is in calling structuralClone when its behaviour wasn’t wanted. With that said, it seems obvious that if you want to globally count the calls, then that count shouldn’t live in an argument where you (the function) don’t control its lifetime or how global it actually is. Simple has no say over what object obj.counter points to, it could trivially be a value type passed into that particular call, so if you know you want a global count then of course storing it in the argument is the wrong choice. Global has two conflated meanings: global lifetime (ie lifetime of the whole program) and global access (which the article states). Simple needs global lifetime but not global access. You rarely ”need” global access, although for things like a logger it can be convenient. Often you do need global lifetime.
  • sublinear 2y ago
    https://en.wikipedia.org/wiki/Dependency_injection https://en.wikipedia.org/wiki/Dependency_injection This is very similar to dependency injection. Separating state and construction from function or method implementation makes things a lot easier to test. In my opinion it's also easier to comprehend what the code actually does.
  • rurban 2y ago
    That's only needed if you use multiple threads. In a single thread global vars are just fine, and much simplier than passing around ctx
    • Tainnor 2y ago
      And do you always know beyond any reasonable doubt that your code will be single-threaded for all time? Because the moment this changes, you're in for a world of pain.
      • christophilus 2y ago
        If JavaScript ever gets real shared memory multithreading, it will be opt in so that the entire web doesn’t break. So, yes.
        • Tainnor 2y ago
          If the discussion here is meant to be solely about JavaScript, then I'll happily consider all my comments in this thread to be obsolete, since I don't have particularly strong opinions about that language since I don't use it a lot. I was under the impression that many people here were discussing the usage of global variables more generally, though.
      • rurban 2y ago
        Wrapping the globals into to a struct context #ifdef MULTI-THREADED and adding this ctx for each call as first call is a matter of minutes. I've done this multiple times. Much worse is protecting concurrent writes, eg to an object or hash table
    • jerf 2y ago
      Even in a single-threaded environment, passing a struct around containing values allows you to implement dynamic scoping, which in this case means, you can easily call some functions with some overridden values in the global struct, and that code can also pass around modified versions of the struct, and so on, and it is all cleanly handled and scoped properly. This has many and sundry uses. If you just have a plain global variable this is much more difficult. Although Perl 5 has a nice feature where all global variables can automatically be treated this way by using a "local" keyword. It makes the global variables almost useful, and in my experience, makes people accidentally splattering globals around do a lot less damage than they otherwise would because they don't have to make explicit provision for scoped values. I don't miss many features from Perl but this is on the short list.
  • dugmartin 2y ago
    This plus immutable data is what makes doing web apps in Elixir using Phoenix so nice. There is a (demi-)god "%Conn" structure passed as the first parameter that middleware and controller actions can update (by returning a new struct). The %Conn structure is then used in the final step of the request cycle to return data for the request. For non-web work genservers in Elixir have immutable state that is passed to every handler. This is "local" global state and since genservers guarantee ordering of requests via the mailbox handlers can update state also by returning a new state value and you never have race conditions.
  • immibis 2y ago
    Or every occurrence of the singleton pattern (except for when it's the flyweight pattern)
• Puts 2y ago
  I think the author forgot the most useful use case for globals, and that is variables that has to do with the context the program is running under such as command line arguments and environment variables (properly validated and if needed escaped).
  • peanut-walrus 2y ago
    Do those change during program runtime though? I don't think many people have problems with global constants.
• bb88 2y ago
  Please no. Singletons if you must. At least you can wrap a mutex around access if you're trying to make it thread safe.
  • bknight1983 2y ago
    For every example of a bug caused by not using a global variable I’m sure could find 10 caused by a global variable
  • grandempire 2y ago
    Why are singletons better? That's just a global object. > wrap a mutex What if my program has one thread? Or the threads have clearly defined responsibilities?
    • rileymat2 2y ago
      You know it is /currently/ accessed on one thread. These are little landmines that add up over time.
      • grandempire 2y ago
        The burden is on the programmer adding a new thread to know what they can safely access. The conclusion of your argument looks like 2000s Java - throw a mutex on every property because you never know when it will need to be accessed on a thread. Designs that spread complexity rather than encapsulate it are rarely a good idea.
        • catlifeonmars 2y ago
          That’s sounds more like a weakness of the language: that preventing data races is not automatically tracked for you, no?
          • liontwist 2y ago
            If you care about performance, many locks across many pieces of shared state is always a bad idea. If you don’t care about performance and want safety you should be using processes. Explicit shared memory is safer than implicit. and yes. Better thread management tools are always welcome when we can get them.
• jongjong 2y ago
  Agreed, global variables are fine up to a certain scale, especially if they're only used in the main file. They only really become a problem if you start modifying them from inside different files. The real underlying problem is 'Spooky action at a distance'; it's not an issue that is specific to global variables. If you pass an instance between components by-reference and its properties get modified by multiple components, it can become difficult to track where the state changes originated and that can create very nasty, difficult-to-reproduce bugs. So this can happen even if your code is fully modularized; the issue is that passing instances by reference means that the properties of that instance behave similarly to global variables as they can be modified by multiple different components/files (without a single component being responsible for it). That's partly where the motivation for functional programming comes from; it forces pass-by-value all the time to avoid all possibility of mutations. The core value is not unique to FP though; it comes from designing components such that they have a simple interface which requires mostly primitive types as parameters. Passing objects is OK too, so long as these objects only represent structured information and their references aren't being held onto for future transformation. So for example, you can let components fully encapsulate all the 'instances' which they manage and only give those parent components INFORMATION about what they have to do (without trying to micromanage their child instances); I avoid passing instances or modules to each other as it generally indicates a leaky abstraction. Sometimes it takes some creativity to find a solution which doesn't require instance-passing but when you find such solution, the benefits are usually significant and lasting. The focus should be on message-passing. Like when logging, the code will be easier to follow if all the errors from all the components bubble up to the main file (e.g. via events, streams, callbacks...) and are logged inside the main file because then any developer debugging the code can find the log inside the main file and then trade it down to its originating component. Methods should be given information about what to do, they should not be given the tools to do their job... Like if you catch a taxi in real life, you don't bring a jerrycan of petrol and a steering wheel with you to give to the taxi driver. You just provide them with information; the address of your desired destination. You trust that the Taxi driver has all the tools they need to do the job. If you do really want to pass an instance to another instance to manage, then the single-responsibility principle helps limit the complexity and possibility for spooky action. It should only be passed once to initialize and then the receiving component needs to have full control/responsibility for that child. I try to avoid as much as possible though.
• grandempire 2y ago
  I've recently found it helpful to think of problems at the scope of an individual process, rather than a set of functions in a library or framework. This makes it much clearer when a global variable makes sense or not, and generally where to initialize things, and place state.
• SpicyLemonZest 2y ago
  > The problem is data access. Nothing more, nothing less. I agree with this, but the problem with global variables is precisely that they make bad data access patterns look easy and natural. Speaking from experience, it’s a lot easier to enforce a “no global variables” rule than explain to a new graduate why you won’t allow them to assign a variable in module X even though it’s OK in module Y.
  • levodelellis 2y ago
    You might like the article I wrote for next week. Could you tell me where this post is linked from? I didn't think anyone would see this when no one commented the first day
• pdimitar 2y ago
  > The problem is data access. Nothing more, nothing less. There's a term for this that has nothing to do with global variables: "action at a distance." I mean yes, using global variables is just one of the ways to cause action-at-a-distance and that is... apparently a big reveal? Otherwise sure, there is no pattern that cannot be utilized 100% correctly and without introducing bugs. Theoretically. Now let's look at the practical aspects and how often indiscriminately using such tempting patterns like global variables -- and mutexes-when-we-are-not-sure and I-will-remember-not-to-mutate-through-this-pointer -- lead to bugs down the road. The answer is: fairly often. IMO the article would be better titled as "There is no pattern that a lazy or careless programmer cannot use to introduce a bug".
• Jtsummers 2y ago
  The bug in the program reveals a poor understanding of object lifecycles by whoever wrote it. The `obj` argument to `simple` is not globally unique and so it makes a poor location to store global state information (a count of how often `simple` is called, in this example). Never tie global state information to ephemeral objects whose lifetime may be smaller than what you want to track. In this case, they want to know how many times `simple` is called across the program's lifetime. Unless you can guarantee the `obj` argument or its `counter` member exists from before the first call to `simple` and through the last call to `simple` and is the only `obj` to ever be passed to `simple`, it is the wrong place to put the count information. And with those guarantees, you may as well remove `obj` as a parameter to both `simple` and `complex` and just treat it as a global. State information needs to exist in objects or locations that last as long as that state information is relevant, no more, no less. If the information is about the overall program lifecycle, then a global can make sense. If you only need to know how many times `simple` was invoked with a particular `obj` instance, then tie it to the object passed in as the `obj` argument.
  • levodelellis 2y ago
    Could you tell me where this was posted? I thought no one would see this after I got no comments the first day No one I showed this to complained about the first example but online many people did. I wrote a completely different article which I think is much better that uses examples I would have used in the follow up. I'll post that article next week
    • Jtsummers 2y ago
      Second chance pool. This post is, per your submission history, from 2 days ago. HN has a second chance pool that lets articles continue collecting upvotes (more easily than digging through the full history). Some of those articles will get their timestamp updated to artificially inflate their ranking. This brings them to the front page again and gives them their "second chance". After a few hours or whatever time, the timestamp is reverted and they'll start falling back into their natural place in the rankings. https://news.ycombinator.com/submitted?id=levodelellis https://news.ycombinator.com/submitted?id=levodelellis https://news.ycombinator.com/lists https://news.ycombinator.com/lists https://news.ycombinator.com/pool https://news.ycombinator.com/pool
• hansvm 2y ago
  Global variables (in languages where they otherwise make sense and don't have footguns at initialization and whatnot) have two main problems: 1. They work against local reasoning as you analyze the code 2. The semantic lifetime for a bundle of data is rarely actually the lifetime of the program The second of those is easy to guard against. Just give the bundle of data a name associated with its desired lifetime. If you really only need one of those lifetimes then globally allocate one of them (in most languages this is as cheap as independently handling a bunch of globals, baked into the binary in a low-level language). If necessary, give it a `reset()` method. The first is a more interesting problem. Even if you bundle data into some sort of `HTTPRequest` lifetime or whatever, the fact that it's bundled still works against local reasoning as you try to use your various counters and loggers and what have you. It's the same battle between implicit and explicit parameters we've argued about for decades. I don't have any concrete advice, but anecdotally I see more bugs from biggish collections of heterogeneous data types than I do from passing everything around manually (just the subsets people actually need).
  • Spivak 2y ago
    I don't think #1 is necessarily true. Take a common case for a global variable, a metric your app is exposing via prometheus. You have some global variable representing its value. Libraries like to hide the global variable sometimes with cuteness like MetricsRegistey.get_metric("foo") but they're globally readable and writable state. And in your function you do a little metric.observe_event() to increment your counter. I think having this value global helps reasoning because the alternative is going to be a really clunky plumbing of the variable down the stack.
    • hansvm 2y ago
      It helps with reasoning in some sense, and the net balance might be positive in how much reasoning it enables, but it definitely hurts local reasoning. You need broader context to be able to analyze whether the function is correct (or even what it's supposed to be doing if you don't actively work to prevent entropic decay as the codebase changes). You can't test that function without bringing in that outer context. It (often) doesn't naturally compose well with other functions.
• billforsternz 2y ago
  From the article> "Static Function Variable: In C inside a function, you can declare a static variable. You could consider this as a local variable but I don't since it's on the heap, and can be returned and modified outside of the functions. I absolutely avoid this except as a counter whose address I never return." These variables are not on the heap. They are statically allocated. Their visibility is the only thing that differentiates them from global variables and static variables defined outside of functions. I think such variables can be useful, if you need a simple way of keeping some persistent state within a function. Of course it's more state you are carrying around, so it's hard to defend in a code review as best practice. Amusingly, you can modify such variables from outside the function, simply by getting your function to provide the modifying code with a pointer to the variable, eg by returning the variable's address. If you do that though you're probably creating a monster. In contrast I think returning the value of the static variable (which the author casts shade on in the quote above) seems absolutely fine. Edit: I should have stated that the number one problem with this technique is that it's absolutely not thread safe for obvious reasons.
  • ijustlovemath 2y ago
    static variable addresses are an extremely important tool in static analysis, for proving certain program invariants hold. In C, a const static often will be able to tell you more about the structure of your code at runtime than a #define macro ever could! though unless you're programming extremely defensively (eg trying to thwart a nation state), I see no reason why you would use them at runtime
    • Panzer04 2y ago
      Could you expand on this? I don't understand the point you're making, or how it's useful.
      • whitten 2y ago
        Perhaps a distinction between static analysis (at compile) and dynamic analysis (at run time) is useful ?
• AdieuToLogic 2y ago
  This assertion made in the article invalidates the premise of same: With a little encapsulation, you can make globals error-proof ...
  • levodelellis 2y ago
    What do you suppose is the recommended way to use the encapsulation? ;) This is partly why there's a "defining global variables" section, I know people will will consider some usage as not using a global
    • AdieuToLogic 2y ago
      > What do you suppose is the recommended way to use the encapsulation? ;) This is partly why there's a "defining global variables" section, I know people will will consider some usage as not using a global What the post discusses can be distilled into the concept of Referential Transparency[0]: A linguistic construction is called referentially transparent when for any expression built from it, replacing a subexpression with another one that denotes the same value[b] does not change the value of the expression. Any construct which is not referentially transparent can be classified as potentially effectual, which is not a Bad Thing(TM) as if there were no observable effects of a program, it would be useless. What makes programs easier to prove correct and reason about is when effects are localized to well-defined areas often "at the edges" of the architecture. What makes programs impossible to prove correct and very difficult to reason about is when effectual logic is pervasive throughout, such as most of the "Global Variable Use Cases" the post advocates. 0 - https://en.wikipedia.org/wiki/Referential_transparency https://en.wikipedia.org/wiki/Referential_transparency
• deleted 2y ago
  [deleted]
• G_o_D 2y ago
  Globals are essential to track state/values of variables in intermediate step, for debug, I create unique object on globals and store intermediate variables in it, so i can inspect values when something goes wrong, being only one unique object to maintain it will not override any existing vars thus not affecting existing programs
• paulsutter 2y ago
  SQL databases are global variables
  • tombert 2y ago
    Or caches! I have gotten shit before for using global variables, and sometimes that is justified, but I almost never see anyone given shit over treating Redis as a big ol’ global map.
    • moring 2y ago
      When it comes to "patterns" and "anti-patterns", double standards are common.
      • tombert 2y ago
        Yeah. Honestly, I think Redis is very often overused and likely makes stuff slower. If your application is only running on one computer, and especially if it's only running in one process, you will likely get better performance using a big ol' thread-safe hashmap that's global/singleton. You pay basically no latency cost, no (de)serialization costs, and the code is likely going to be simpler. I've seen people who seem to think that just inserting stuff into Redis will somehow automatically make their code better, only for the code to actually become slower because of network latency. I've also seen people use Redis as a way to have global variables because it's too hard to figure out how to scope stuff correctly.
  • macintux 2y ago
    And man, the bugs they cause.
    • nejsjsjsbsb 2y ago
      Man, the bugs they prevent. Vs everyone rolling their own multithreaded file reader/writer code in C. How many programmers would think to journal transactions and ship them for backup for example. SQL or 15000 lines of C++ or Go or Rust doing whatever with files.
• senderista 2y ago
  Instance variables are to instance methods what global variables are to free functions and have exactly the same problems.
  • khana 2y ago
    [dead]
• qalmakka 2y ago
  mutable global variables are intrinsically incompatible with a multithreaded environment. Having mutable shared state is never the right solution, unless you basically can live with data races. And that's before taking maintainability in consideration too
• Joel_Mckay 2y ago
  There are only a few use-cases where global variables make sense: 1. Thread container registry with mutex lock for garbage collection and inter-process communication (children know their thread ID) 2. volatile system register and memory DMA use in low level cpu/mcu (the compiler and or linker could pooch the hardware memory layout) 3. Performance optimized pre-cached shared-memory state-machines with non-blocking magic 4. OS Unikernels Not sure I have seen many other valid use-cases that splatter language scopes with bad/naive designs. YMMV =3
• PeterStuer 2y ago
  The one where the author almost rediscovers the singleton pattern.
  • cauefcr 2y ago
    It can also be an almost rediscovery of closures.
• js8 2y ago
  Any program that uses a database has a very similar problem to global variables. As Gilad Bracha has pointed out, types are antimodular, and your database schema can be considered one giant type that pervades your program, just like globals can be. I don't think we have tools to compositionally solve this, across different programming languages.
  • cauefcr 2y ago
    Migrations? Generate bindings for your queries automatically with query+schema definitions? (sqlc)
  • nejsjsjsbsb 2y ago
    Your program is also one giant type.
    • js8 2y ago
      Yeah but I don't use that type in 100s of places.
• fergie 2y ago
  Surely both of the examples in the article are using global variables? Nobody ever said global variables are ok if they are an object? (Or did they?)
• Tainnor 2y ago
  > If you run the code you'll see 1 2 3 4 3 printed instead of 5. I'm really confused, as this behaviour appears to be completely obvious to me.
  • gbalduzzi 2y ago
    Yeah in the example it was obvious. Of course in a real life program, it may be lost in other code logic and, most importantly, the function performing the clone may not be so explicit about it (e.g. an "update" function that returns a different copy of the object).
• tedk-42 2y ago
  Global variables are fine when you read many times, but you write to them sparingly and when they are updated but the old value is read/used you have mechanisms to handle errors and retry
• brainzap 2y ago
  There are also things like translation, environment details and logger, which I wish were always present, like a super global.
• 2d8a875f-39a2-4 2y ago
  "Guns aren't the problem, it's all the people pulling triggers."
• robertlagrant 2y ago
  I think this article broadens the definition of global variable and then says "Look, the things I added to the definition aren't bad, so global variables aren't always bad." If you just look at what people normally mean by global variable, then I don't think the article changes minds on that.
  • berkes 2y ago
    To make it worse: "Look, the things I added to the definition aren't bad in this specific language and use-case, so global variables are not the problem". To me, the author either has a very narrow field of focus and honestly forgets about all the other use-cases, practicalities and perspectives, or they choose to ignore it just to fire up a debate. In any case, these constructs are only true for JavaScript (in node.js whose setup avoids threads common issues), and fall flat in a multithreaded setup in about every other languages. If I were to port this to Rust, first, the borrow checker would catch the described bugs and not allow me to write them in the first place. But secondly, if I really insist on something global that I need to mutate or share between threads, I can do so, but would be explicitly required to choose a type (Mutex, RwLock, with Arc or something) so that a) I have thought about the problem and b) chose something that I know to work for my case.
    • robertlagrant 2y ago
      > If I were to port this to Rust, first, the borrow checker would catch the described bugs and not allow me to write them in the first place. But secondly, if I really insist on something global that I need to mutate or share between threads, I can do so, but would be explicitly required to choose a type (Mutex, RwLock, with Arc or something) so that a) I have thought about the problem and b) chose something that I know to work for my case. Agreed. Not the specifics, as I don't know Rust, but it makes sense.
• anymouse123456 2y ago
  Please. Just don't. Moving state into the global namespace and accessing it directly from that space makes it much more difficult to test, instrument and integrate. Sure, if you're building disposable toy software, do whatever is easiest. But if you're building software for others to use, at least provide a context struct and pass that around when you can. For those cases where this is challenging or impossible, please sequence your application or library initialization so that these globals are at least fungible/assignable at runtime.
• darioush 2y ago
  Global variables are a programming construct, which like other programming constructs is neither bad nor good. Except, due to the takeover of workplaces by the best practices cult, instead of reasoning about tradeoffs on a case by case basis (which is the core of coding and software engineering), we ascribe a sort of morality to programming concepts. For example, global variables have drawbacks, but so does re-writing every function in a call-stack (that perhaps you don't control and get callbacks from). Or if you are building a prototype, the magic of being able to access "anything from anywhere" (either via globals or context, which is effectively a global that's scoped to a callstack), increases your speed by 10x (since you don't have to change all the code to keep passing its own abstractions to itself as arguments!) Functions with long signatures are tedious to call, create poor horizontal (which then spills over to vertical) code density. This impacts your ability to look at code and follow the logic at a glance, and perhaps spot major bugs in review. There's also fewer stuff for say copilot to fill in incorrectly, increasing your ability to use AI. At the end, every program has global state, and use of almost every programming construct from function calls (which may stack overflow) or the modulus operator (which can cause division by zero), or sharing memory between threads (which can cause data races) requires respecting some invariants. Instead, programmers will go to lengths to avoid globals (like singletons or other made up abstractions -- all while claiming the abstractions originate in the problem domain) to represent global state, because someone on the internet said it's bad.
  • cogman10 2y ago
    Depends a bit on the language. A global variable in a language with parallel operation is often a terrible idea. The problem with globals and parallel operations is they are an inherent risk for race conditions that can have wild consequences. In some languages, for example, a parallel write to a field is not guaranteed to be consistent. Let's assume in the above example `counter` was actually represented with 2 bytes. If two threads write an increment to it without a guard, there is no guarantee which thread will win the upper byte and which will win the lower byte. Most of the time it will be fine, but 1 in 10k there can be a bizarre counter leap (forwards or backwards) that'd be almost impossible to account for. Now imagine this global is tucked away in a complex library somewhere and you've got an even bigger problem. Parallel calls to the library will just sometimes fail in ways that aren't easy to explain and, unfortunately, can only be fixed by the callee with a library wrapping synchronization construct. Nobody wants to do that. All of these problems are masked by a language like Javascript. Javascript is aggressively single threaded (Everything is ran in a mutex!). Sure you can do concurrent things with callbacks/async blocks, but you can't mutate any application state from 2 threads. That makes a global variable work in most cases. It only gets tricky if you are dealing with a large amount of async while operating on the global variable.
• sennalen 2y ago
  Did a global variable write this?
• debeloo 2y ago
  It's just like saying guns are not the problem. Perhaps a unicorn doesn't die as soon as you first use a global var. But it has two .45s pointed to it cranium left and right. And at any random moment Danni DeVito will start blasting.
• stickfigure 2y ago
  The problem with global variables is that they imply that there's only one of that thing. This assumption - no matter how certain it seems - will inevitably be proven false in any sufficiently long-lived software component.