Global variables are not the problem

> it is the wrong place to put the count information.

I'd argue this is the case regardless of lifetime. It's trying to squash two unrelated things into one object and should have been two different arguments.

Way more obvious if "obj" is replaced with some example object instead of an empty one:

  let person = { name: "Foo Bar", age: 30, counter: counter };

I like the diagnosis.

My JS is terrible, but it seems like once you make the counter a global variable it is just better to change it to have an atomic dedicated count function. So instead of incrementing the counter in simple, a globalCount() function gets called that isolates the state. Something like

  {
    let i = 0;
    var counter = function (){
        console.log(++i);
    }
  }

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

The counter should be declared as static inside the function, thus limiting is scope and avoiding pollution of the global namespace.

[dead]

> 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.

In C++, there is a difference: function-static variables get initialized when control first passes into the function. That difference matters in cases where the initial value (partly) comes from a function call or from another global. For example, in C++ one can do:

  int bar = -1;

  void foo() {
    static char * baz = malloc(bar);
    …
  }

  void quux() {
    bar = 13;
  }

They added that feature not to support such monstrosities, but because they wanted to support having static variables of class type.

If they were to design that today, I think they would require the initialization expression to be constexpr.

Just in case anyone still doesn't understand what that means to be statically allocated. It means that they are allocated in the Data Segment, which is a separate area of virtual memory from the stack and the heap.

Sorry, I owe the author an apology for saying that they "cast shade" on the idea of returning the value of the static variable. Actually they, quite correctly, cast shade on the idea of returning the address of the static variable. I'd edit the original message, but I am (far) too late. I just noticed my mistake. All I can do is add this apology, for the record.

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

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.

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.

> 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.

You're just strawmanning here. Maybe some of the people who say that global variables should be avoided ("should be avoided" never means "absolutely can't be used ever", btw) are people who have experience working on large projects where the use of implicit state routinely makes code hard to reason about, causes concurrency issues and introduces many opportunities for bugs.

> There's also fewer stuff for say copilot to fill in incorrectly, increasing your ability to use AI.

That argument makes no sense to me. If some piece of code is relying on implicit global state to have been set, why would copilot be any better at figuring that out than if it had to pass the state as an argument, something which is clearly stated in the function signature?

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.

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.

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.

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.

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

The "god object"

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.

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

Or every occurrence of the singleton pattern (except for when it's the flyweight pattern)

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

It can also be an almost rediscovery of closures.

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?

For every example of a bug caused by not using a global variable I’m sure could find 10 caused by a global variable

You may hate my article next week, it's meant to replace this article. If you want you can email me for early access and tell me how I can improve the article. Lets say you can guess my email if you're emailing the right domain

You say "thread safe", I say "dead lock".

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

Do those change during program runtime though? I don't think many people have problems with global constants.