[kibwen]

Outside of single-initialization/lazy-initialization (which are provided via safe and trivial standard library APIs: https://doc.rust-lang.org/std/sync/struct.LazyLock.html ) almost no Rust code uses global mutable variables. It's exceedingly rare to see any sort of global mutable state, and it's one of the lovely things about reading Rust code in the wild when you've spent too much of your life staring at C code whose programmers seemed to have a phobia of function arguments.

[dxxvi]

> It's exceedingly rare to see any sort of global mutable state I know a bit of Rust, so you don't need to explain in details. How to use a local cache or db connection pool in Rust (both of them, IMO, are the right use case of global mutable state)?

[adastra22]

You wrap it in a mutex and then it is allowed.

Global state is allowed. It just has to be thread safe.

[therein]

Why does that have to be global? You can still pass it around. If you don't want to clobber registers, you can still put it in a struct. I don't imagine you are trying to avoid the overhead of dereferencing a pointer.

[spacechild1]

I think a better example might be logging. How is this typically solved in Rust? Do you have to pass a Logger reference to every function that potentially wants to log something? (In C++ you would typically have functions/macros that operate on a global logger instance.)

[whytevuhuni]

In Rust you typically use the "log" crate, which also has a global logger instance [0]. There is also "tracing" which uses thread local storage.

As another comment said, global state is allowed. It just has to be proven thread-safe via Rust's Send and Sync traits, and 'static lifetime. I've used things like LazyLock and ArcSwap to achieve this in the past.

[0] https://docs.rs/log/latest/log/fn.set_logger.html

[dxxvi]

I wonder what the advantage of passing it around is when it makes the argument list longer. The only advantage that I can see is that it emphasizes that this function does something with cache.