I'm guessing you still are able to use a singleton, no?

Singletons still require globals. I haven't really dug into V that much, is there a mechanism to make a singleton? If so, how can they claim "no global variables?"

I'm curious, can you make an example?

POSIX signal handlers don't take an argument other than the signal code, so if you want to handle them gracefully in a stateful app you need a global to communicate the trapped signal to your main loop.

Closures could be used to implement this use case, provided that they can be exported/represented as native C function pointets, e.g. via a trampoline that captures the necessary captured context)

How would you implement the trampoline without a global? And would the captured context not count as a global?

In C the only memory available to a function is its arguments and data with static duration. That static storage is synonymous with global state, if it isn't known at compile time.

We have to distinguish what the given language exposes to its users and how the code such language generated works on the underlying hardware (along with constraints due to compatibility with other languages, most importantly C which is the de-facto system interface nowadays).

A C-compatible closure basically requires an executable chunk of memory that captures the state along with the istructions to push it to the parameters area (based on the architecture's calling convention) and then jumping to the actual function.

This is not global just because it's scoping the state with the function. On the other hand it becomes global the moment it gets installed to a global handler table (because there can only be one such handler).

However a language that limits globals (and forces people through this kind of hoops in order to deal with cases where singletons are really needed) encourages a coding style that makes it easier to test your code in isolation.

Eh, not a big deal.

Just move "global" (aka: main() ) up 1 function. And then, run everything in that function. Hell, it could be a try-catch loop equivalent.

That kind of assumes you have a main() function.

There is not a single situation where global variables are necessary.

Global logging in libraries is not uncommon, especially if you need to trap signals (which can only interact with global state).

COM APIs expose a global class factory as the main interface to a shared libraries.

Embedded systems and drivers require globals in one form or another.

"Globals are evil" comes from the fact that globals have side effects, and side effects make things hard, especially in modern software that utilizes asynchronous/concurrent logic. That just makes them unwieldy, not unnecessary. Especially when interacting with legacy systems that require globals.

I take it you've never programmed embedded?

Yeah, state sucks. But sometimes, you need a starting point, and diff from that. And, that's state.

One of the safe ways of handling global vars, is by having only a single non-interruptible function that can mutate global. And you have best make sure your global-mutating function is fast. You don't want to miss IRQs that might fire off but are blocked.

Yes, embedded is enough of a special case that I don’t consider it as part of a general purpose discussion on programming languages.

Ericsson predicts 18 billion IoT devices by 2022. Those all need code written for them. Do you still consider embedded programming a "niche"? Maybe it's one specific case, but it's relevant and ought to be "part of the discussion".

https://www.ericsson.com/en/mobility-report/internet-of-thin...