> OpenGL has one global state.

As far as I know, it doesn't, it's actually thread-local state; you can have multiple states, and you use glXMakeCurrent/eglMakeCurrent to choose which one is active for the current thread.

And the protocol which can be considered the successor of OpenGL (Vulkan) replaced the thread-local state with an explicit reference to the state.

> A database connection is a global.

The product I develop at work uses multiple database connections, to several different databases, which can be added and removed at runtime. They most definitely aren't global.

Because that's the academic answer that doesn't have to deal with real world constraints and pressures. I too have a deep hatred of the "you don't want to do that" answer for this reason: I do deal with real world constraints and pressures and I'm asking my question because "the right way" can't be done in my circumstances!

To quote myself, “it should be avoided”, doesn’t mean never.

DB connections as global state, I might go as far as saying global for a single thread, ie it might be reasonable to have a thread-local-storage for checked out connections. I still would keep access to that thread-local restricted, and keep most of the code more testable by having the connection be a parameter to each function.

I disagree with that in general (but certainly won't argue against certain very specific use cases). Being diligent about testing has made me loathe global objects; it's so much easier to write a test for a function that makes a database query when I can pass in a mock database object, rather than having to patch the environment to make that same function use a global mock. If you can get to the point that almost all tested functions operate only on things passed into them as arguments, some previously difficult things can become almost trivial.

I don't dislike global state because of some lofty goals I memorized back in college and have held up as supreme truth, but because practical experience tells me that it makes my life as a programmer more complicated than it has to be.

What happens if you need to use your code to migrate from one database to another, but all the low level logic uses a single global database connection?

How do you test that your program behaves the same way with a reference software renderer and the GPU if there’s only one global handle to the video card?

In both cases, how do you add more threads without creating a global lock?

There are cases where you only have 1 instance of something, never 2 or more. Most developers use such things dailyu, like in JS you have the window object, most of the time you don't pass the window as a parameter in all your functions but in one project I worked it was a requirement to pass the document as a param in all functions that needed it. So the my opinion is that it depends, sometimes having a World,App,Window etc global helps more then it causes issues and is preferable to a solution that is pure that costs you more. FYI I use a functional style as much as possible, no side effects but sometimes pragmatism wins, in my current project I guarantee we won't change our database or upgrade the current framework to a new cooler one.

> There are cases where you only have 1 instance of something, never 2 or more.

I've seen plenty of cases where this assumption stops being true and only through pain and sweat the design could be disentangled after the fact. On the other hand I've never been more than mildly inconvenienced by in practice global state that had an API that didn't assume it.

Writing the logic as if it could be more than one at a time also makes it much easier to write isolated tests and reduced integration tests.

I have always seen singleton designs in codebases where testing was wanting.

As I said it depends, do you pass in js the Math object around because you assume that in future you want to replace the Math.abs function with something different ?

Sure I seen the issues you mentioned too and many other issues where the initial requirements or assumptions changed.

The OpenGL is a much better example than the database connection, FWIW.

In what sense is a DB connection global? You can easily have multiple DB connections in one program.

Its dogma. Like a religion. A whole generation of people believing in things with no root evidence except that the knowledge is ubiquitous

I have plenty of history with global state, various contexts in large applications, that make testing code unnecessarily complex.

So, yes, global state is sometimes necessary, but it absolutely should be avoided, and access to it should be restricted.