Why do you need mutable access to this variable everywhere in your program? Convinient way to solve this problem is to create the configuration struct (Global in your case, but i would rename it to smthng like Config) on very beginning of program, and then pass it wherever its needed. Global mutable state, however achieved, is in general an evil idea.

The main problem with mutable statics is that they are only memory-safe in the right usage conditions. Set them and read them concurrently from two different threads and you get a data race. This dependency on correct usage patterns is the very defining characteristic of unsafe in Rust, so hiding the unsafety through encapsulation as you are doing here is not correct.

Note that an abstraction that uses unsafe internally is not problematic in and of itself. Otherwise, you wouldn’t even be able to use the std library.

What is unacceptable is exposing an interface which pretends to be safe, but can break type/memory/thread-safety if used in the wrong way. Or, in more advanced usage scenarios, exposing an unsafe interface without documenting under which assumptions this interface is safe.

Unsafe in code means “Dear compiler, please let me do some things which are potentially memory/type/thread-unsafe”, whereas unsafe in interfaces means “Dear user, this interface is only safe if specific precautions are taken when using it, please be careful with that contract”.

I find it just inconvenient to pass Config around as I change it (if the option was specified at the command line) a single time at program start.

I would say this is actually a good thing. By having to explicitly pass in the information you need it’s very easy to see which parts of an application depend on what. It also tends to make testing and maintaining things a lot easier in the long run (e.g. with dependency injection and all that).

I’ve spent quite a long time writing Rust code and then when I started working on a C# application at work I found that having globals is a great way to accidentally make a tightly coupled ball of spaghetti.

I originally started programming using Python and when I saw Rust forcing you to stop using globals my reaction was quite similar. My advice would be to give it a try and see how your application works out by populating your Config struct in main() then passing references to the bits of code which need it.

While it’s valuable and important to understand why Rust makes globals a PITA, it’s also important to acknowledge that sometimes they’re useful, particularly when the application is small/immature. That’s partly the reason crates like lazy_static exist in the first place. Once the application reaches a certain size, it’s possible to refactor away from the global if it becomes a problem.

In my case the single bool was the minimal example. In my real cmdline app I (currently) have 9 options.

8 of them I could easily pass around as they were used only in 1 or 2 functions. The 9th was the beast which I really need in many places as that option --no-colors tells the application to not use colored crate when issuing messages.